Ticket 314

Summary:	sview scalability issues
Product:	Slurm	Reporter:	Yiannis Georgiou <yiannis.georgiou>
Component:	Other	Assignee:	Moe Jette <jette>
Status:	RESOLVED DUPLICATE	QA Contact:
Severity:	3 - Medium Impact
Priority:	---	CC:	da
Version:	2.6.x
Hardware:	Linux
OS:	Linux
Site:	Universitat Dresden (Germany)	Alineos Sites:	---
Atos/Eviden Sites:	---	Confidential Site:	---
Coreweave sites:	---	Cray Sites:	---
DS9 clusters:	---	HPCnow Sites:	---
HPE Sites:	---	IBM Sites:	---
NOAA SIte:	---	OCF Sites:	---
Recursion Pharma Sites:	---	SFW Sites:	---
SNIC sites:	---	Linux Distro:	---
Machine Name:		CLE Version:
Version Fixed:		Target Release:	---
DevPrio:	---	Emory-Cloud Sites:	---

Description Yiannis Georgiou 2013-06-04 04:47:34 MDT

In TU-Dresden cluster we observed problems with sview which hangs if many jobs have been submitted/are managed by SLURM . The cores where sview is running go to 100% CPU load, and sview stops updating the information in the GUI.

Have you seen this before? Are there configuration parameters that we can change to improve the scalability of sview ?

thanks 
Yiannis

Comment 1 Danny Auble 2013-06-04 04:51:27 MDT

How many jobs are you talking about?  I am guessing thousands.  There is probably work that could be done in terms of scalability.  There is so much going on with sview that does need to, like updating buttons that are not visible and such.

I would propose we look at some way to only change the status of what is currently displayed.  I am not sure how difficult that will be.

Comment 2 Moe Jette 2013-06-04 12:12:11 MDT

I did some scalability testing with sview a few years ago. My recollection is that sivew was unable to manage more than a couple thousand elements (nodes, jobs, or whatever). Almost all of the time was consumed by the underlying GTK library. Some enhancements were made to improve performance, but I'm not sure how much more is possible except by reducing the number of elements displayed, say only showing the highest priority jobs instead of all jobs.

Comment 3 Danny Auble 2013-06-21 07:38:32 MDT

Another bug with a possible patch was made for this issue, so marking it as duplicate.

*** This ticket has been marked as a duplicate of ticket 345 ***