Open

Overview

This report compares the CPU utilization patterns observed during data export operations in the Ramsons and Sunflower environments. The purpose is to highlight performance differences and identify potential reasons why the Sunflower environment is approximately 2x slower in completing data exports, particularly for larger datasets.

Key Observations

Ramsons Environment

• 14:35: A 100k record export (Default profile) caused a minor CPU uptick (~5%).

• 14:45: A 500k export (Default profile) triggered a sharp spike in CPU usage—peaking around 26% on one instance.

• 15:10: Another 500k export using the SRS holdings and items profile resulted in a second peak—up to ~35.6%.

• Performance: The spikes were short-lived, and CPU usage returned to baseline quickly, indicating efficient processing and resource handling.

Sunflower Environment

• 07:40–08:15: Two 100k exports (one Default, one SRS) led to mild CPU fluctuations.

• 08:20: A 500k export (Default profile) caused a moderate CPU spike (~21%).

• 09:15–09:25: A 500k export (SRS profile) resulted in sustained CPU utilization across multiple instances, peaking around 21.5%, but lasting nearly 10 minutes.

• Performance: CPU load was more prolonged and distributed across instances. The system took significantly longer to complete the exports.

Conclusion: Sunflower Is Slower (~2x) Compared to Ramsons

Although Ramsons shows higher CPU peaks during export jobs, it consistently completes the tasks in shorter time frames. Sunflower, on the other hand, exhibits lower peak CPU but longer sustained utilization, indicating slower job execution. This aligns with the observation that Sunflower is approximately 2x slower in completing large export tasks.

Open

Observation Timeframe: 07:30–09:30 UTC
Key Metrics:

• 100k export (Default and SRS):

  • Both operations push CPU usage above 10%, higher than Ramsons under similar load.

  • Indicates that even smaller exports in Sunflower require more CPU time.

• 500k export (Default):

  • mod-data-export-b spikes dramatically to ~88%, more than double Ramsons' peak for the same job.

  • The spike is also sustained for ~5–6 minutes, rather than short and sharp.

• 500k export (SRS):

  • CPU usage hovers between 50–65% across services for over 10 minutes.

  • Clearly shows longer processing time and more sustained system pressure.

Interpretation:
Sunflower shows consistently higher and longer-lasting CPU usage, implying slower processing and less efficient handling of the export workload.

🆚 Comparison Table

Analysis & Highlights

• Sunflower is nearly twice as slow as Ramsons during 500k exports, despite showing higher CPU usage — especially evident in the SRS export.

• 100k export CPU usage is higher in Sunflower, suggesting less optimization even for smaller jobs.

• mod-data-export-b service in Sunflower hits 88%, which is double Ramsons' peak (42%) during the same 500k Default export. This suggests:

  • Potential CPU starvation or throttling elsewhere.

  • Less efficient threading or job execution settings.

  • Possibly higher contention or background load in Sunflower.

  • In Ramsons mod-inventory was the second but mod-inventory-storage was second in Sunflower env.

Open

This comparison evaluates the performance of the data export feature in terms of database utilization across two environments—Ramsons and Sunflower—using two export profiles: d and srs.

Ramsons Environment:

• For an export of 500K records:

  • The d profile resulted in approximately 32% database utilization.

  • The srs profile showed a higher utilization of around 44%.

• Observation: The srs profile in Ramsons consumes significantly more database resources than the d profile for the same data volume, indicating it may be less efficient or more resource-intensive.

Sunflower Environment:

• For 500K records:

  • The d profile reached 48% utilization.

  • The srs profile peaked at 58%.

• For 100K records:

  • Interestingly, the d profile showed a very high utilization of 74%, which is unusually high for a smaller dataset.

  • The srs profile reported a more moderate 52% utilization.

Additional Observation:

• At around 8:50 AM in the Sunflower environment, a database utilization of approximately 50% was observed even though no export activity was occurring. This unexpected load may indicate background processes, system overhead, or anomalies in resource management.

Summary:

• The srs profile consistently consumes more resources than d at the 500K level in both environments.

• The d profile in the Sunflower environment shows an unusual spike in usage at 100K, potentially pointing to inefficiencies or configuration issues.

• Idle-time database load in Sunflower also warrants investigation to identify potential bottlenecks or background operations.

Open

Comparison Summary

Notable Observations – Why Sunflower May Be Performing Poorly

1. CPU Saturation

   • In Sunflower, AAS often hits or exceeds max vCPU (dotted line), especially during 500k jobs.

   • In contrast, Ramsons stays well below vCPU saturation, even at similar volumes.

2. More Update-Heavy Workload

   • Sunflower shows heavier use of UPDATE statements (especially mod_users, mod_inventory_storage, etc.).

   • These are more CPU- and I/O-intensive than SELECT or INSERT alone — contributing to high load.

3. Frequent Autovacuum/Analyze

   • More autovacuum and ANALYZE entries in Sunflower — indicates table churn or poor vacuum tuning.

   • Autovacuum can clash with workload, causing contention.

4. Longer Sustained Load

   • Sunflower load is sustained over longer periods vs. the short bursts in Ramsons.

   • Suggests poorer query optimization or longer query runtimes.

5. Possibly Misaligned JVM/Container Settings

   • Based on prior screenshots, container memory/CPU allocations (soft/hard limits) might not be sufficient or aligned in Sunflower.

   • This could cause GC thrashing or CPU starvation under load.

Conclusion

Ramsons handles both default and SRS profiles more gracefully even at higher volumes.

Sunflower struggles with:

• CPU saturation,

• Update-heavy query mix,

• High autovacuum activity,

• Longer query runtimes.

Cluster Resources - secp1-pvt (Tue May 06 09:21:45 UTC 2025)