[functional] Low performance on openqa production server
|Category:||Bugs in existing tests|
|Target version:||QA - future|
We have this problem for quite long time. send_key sometimes doesn't work, command input lost sometimes characters, timeout issue for match needles etc.
yast2_gui test, for example yast2_control_center.pm had a lot of failures, and we needed to workaround issues mentioned above (like add assert_screen extra after send_key).
Some tickets for sporadic issue related to low performance of openqa server:
We should do checks on performance status of production server.
Just say we don't have no problems with server performance is not enough
To know how many workers on openQA production server can be run without performance issue
for example: hardware configurations (cpu, mem) and their assignment to worker/test
to limit amount of workers if performance issue rises
#6 Updated by okurz over 1 year ago
- Description updated (diff)
- Category set to Bugs in existing tests
- Target version set to future
hi, in redmine it's better to reference other tickets with just
#<id> so that we can see a preview and also the reference is striked through if already closed. Also some of the referenced issues are IMHO not pointing to low performance on specific workers but actually real issues which we needed to fix specifically as well as the limits of running single core VMs with 1GB of RAM or hardly more. What we can do though is to bump the memory we supply to the VMs as well as try to experiment with setting at least 2 cores by default.
Let's keep this ticket open for now and reference other related issues to see commonalities first before going further.
#10 Updated by okurz over 1 year ago
Sorry, after reviewing the current test failures I do not buy into the argument of "low performance on production server". #39059 gives more details. As riafarov also investigated in jobs we more likely have a problem still/again with https://bugzilla.suse.com/show_bug.cgi?id=1063638 . If there is anything else in specific cases then we should handle such as specific ones. Mentioning seemingly related job failures here should be beneficial nevertheless.