William, thank you for your reply,
The issue is that it did work that way with SGE 6.1u6 - even when the reporting variable was not reported multiples of the load_report_time it still remembered its previous value and stored it. Looks like in SGE 8.1.8 it drops reporting variables which are not reported during 'load_report_time' almost immediately. Is there a way in SGE 8.1.8 to rise the timeout (ttl) for reporting variables which are not being reported for multiples of the load_report_time? Regarding the suggested approach - it will still pass the value from the execution host to the Grid Master. Is there a way not passing the value that frequent and instead reuse previous value for particular reporting variable? Thank you! -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Wednesday, March 25, 2015 2:00 PM To: [email protected] Subject: users Digest, Vol 51, Issue 10 Send users mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://gridengine.org/mailman/listinfo/users or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of users digest..." Today's Topics: 1. Re: Issue with reporting variables on SoGE 8.1.8 - variables and their values dissapear after some time (William Hay) ---------------------------------------------------------------------- Message: 1 Date: Tue, 24 Mar 2015 12:08:00 +0000 From: William Hay <[email protected]> To: [email protected] Subject: Re: [gridengine users] Issue with reporting variables on SoGE 8.1.8 - variables and their values dissapear after some time Message-ID: <[email protected]> Content-Type: text/plain; charset="utf-8" On Tue, 24 Mar 2015 11:26:04 +0000 Yuri Burmachenko <[email protected]> wrote: > Hallo to distinguished forum members, > > I hope you can assist me. > We are in process of transition to SoGE 8.1.8 from SGE GE 6.1u6. > > We experience strange issues with reporting variables. > For example we have a reporting variable called mt_os_type which returns OS > type. > > Output example 1: centos6 > Output example 1: centos5 > > #name shortcut type relop requestable > consumable default urgency > #------------------------------------------------------------------------------------------------------- > mt_os_type mt_os_type STRING == YES > NO NONE 0 > > qconf -se global | grep -i mt_os_typeL > mt_syslog_bytes,mt_yp_query_ms,mt_os_type > > It works OK on SGE GE 6.1.u6, while on SoGE 8.1.8 it behaves inconsistently: > it appears and after some time the variable and its value disappears from > attributes on execution hosts. > qconf ?se <some_host> | /bin/grep ?i <some_host>: > mt_os_type=centos5 > > And after a minute: > qconf ?se <some_host> | /bin/grep ?i <some_host>: > > No variable and no value? > > Some additional information: > > Report time is (qconf ?sconf): > load_report_time 00:00:40 > > > Within load_sensors.sh script we use several types of sensors: the ones which > are invoked every 40 sec and other that invoked every 2 and 5 minutes, see > below: This looks like working as designed to me. A load sensor value hasn't been reported for multiples of the load_report_time so it is now unknown. If this didn't happen a problem that broke the load sensor wouldn't be detected. If you are trying to avoid running load sensors more than necessary I would suggest caching the results of the infrequently run sensors and reporting the cached values every time. You can save the output of the infrequent sensors to a file and then cat it back every time the load_sensors.sh script is prompted for values. -- William Hay <[email protected]> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://gridengine.org/pipermail/users/attachments/20150324/6d8acbba/attachment-0001.sig> ------------------------------ _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users End of users Digest, Vol 51, Issue 10 ************************************* _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
