Hi Reuti, Here is the original post I was talking about...
https://blogs.oracle.com/templedf/entry/performance_considerations_for_jsv_scripts Because the server-side JSV scripts are executed by the qmaster for every job, there are performance considerations that must be taken into account. In order to limit the performance impact, the qmaster will manage the JSV scripts the same way load sensor scripts are handled, i.e. they are started once and kept alive as a separate process instead of starting them once per job. Nonetheless, what happens inside the scripts can still have a big impact on qmaster performance. Indeed, the perl jsv on the server side does not exit and stays alive...at least for me.... $ top -u sge -n 1 -b top - 16:38:56 up 10 days, 21 min, 1 user, load average: 0.08, 0.02, 0.01 Tasks: 150 total, 1 running, 149 sleeping, 0 stopped, 0 zombie Cpu(s): 1.0%us, 0.3%sy, 0.0%ni, 98.4%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 3925920k total, 1480684k used, 2445236k free, 177004k buffers Swap: 4194296k total, 2080k used, 4192216k free, 609264k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3448 sge 20 0 912m 67m 10m S 0.0 1.8 244:46.60 sge_qmaster 26612 sge 20 0 29212 3668 1740 S 0.0 0.1 0:48.61 SystemJSV.genom 26613 sge 20 0 29212 3668 1740 S 0.0 0.1 0:48.41 SystemJSV.genom $ ps -eLf |grep jsv lauzeox 13542 12060 13542 0 1 16:43 pts/0 00:00:00 grep jsv sge 26612 3448 26612 0 1 May21 ? 00:00:48 /usr/bin/perl /genomics/gridengine/soge/util/jsv/SystemJSV.genomics.pl sge 26613 3448 26613 0 1 May21 ? 00:00:48 /usr/bin/perl /genomics/gridengine/soge/util/jsv/SystemJSV.genomics.pl Thanks, Ed -----Original Message----- From: Reuti [mailto:[email protected]] Sent: Wednesday, May 29, 2013 06:46 PM To: 'Ed Lauzier' Cc: [email protected] Subject: Re: [gridengine users] JSV - parameter updates and restart methodologies Am 29.05.2013 um 23:38 schrieb Ed Lauzier:> AFAICT, the perl jsv threads stay running for performance reasons> as was talked about way back when...Not for me. The JSV will exit by calling "jsv_accept" or alike - being it a shell or perl script. Can you please post an output of `ps -eLf` with the alive threads of the JSV.-- Reuti> Having values updateable by adjusting a parameters file and> having the threads update it's own parameters by checking every > 3 minutes or so for a change may work nicer than having to> kill them off so that they restart again...kinda of an incomplete> integration....> > I'll look into a possible solution for this as it should be relatively easy...> esp on verify...we could check a timer quick to see if the min time> to check has expired...and if so, check the file for parameter diffs> and set them if so - thereby eliminating the need to restart the> jsv perl threads....On a large cluster, you can have say 4-8 threads> running.....depending on the bootstrap config file values.> > -Ed> > -----Original Message-----> From: Reuti [mailto:[email protected]]> Sent: Wednesday, May 29, 2013 04:58 PM> To: 'Ed Lauzier'> Cc: [email protected]> Subject: Re: [gridengine users] JSV - parameter updates and restart methodologies> > Am 29.05.2013 um 22:42 schrieb Ed Lauzier: > I've been running perl JSV server side scripts and they run fine. > When they need updating is when we have to do things > alittle crude at the moment. ( kill them and have the scheduler > restart them on the next job submission...) You mean they are running in a loop like a load sensor instead of being started for each job submission? -- Reuti > Would it be possible to set a parameter update interval so that > all we would have to do is edit a parameters file and the parameters needed > for the JSV to set runtime limits for example would update itself.... > > Has this already been done? If so, please let me know the methodology > used in implementing such a solution. > > Thanks, > > Ed Lauzier > > _______________________________________________ > users mailing list > [email protected] > https://gridengine.org/mailman/listinfo/users> _______________________________________________> users mailing list> [email protected]> https://gridengine.org/mailman/listinfo/users
_______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
