> Am 23.03.2017 um 09:11 schrieb John_Tai <john_...@smics.com>: > > Can I still download 6.2? Haven't been able to find it. > > John
You can make use of the open source update: http://arc.liv.ac.uk/downloads/SGE/releases/8.1.9/ from https://arc.liv.ac.uk/trac/SGE -- Reuti > > -----Original Message----- > From: Reuti [mailto:re...@staff.uni-marburg.de] > Sent: Wednesday, March 22, 2017 8:27 > To: John_Tai > Cc: Christopher Black; users@gridengine.org; Coleman, Marcus [JRDUS Non-J&J] > Subject: Re: [gridengine users] John's cores pe (Was: users Digest...) > > Hi, > >> Am 22.03.2017 um 04:24 schrieb John_Tai <john_...@smics.com>: >> >> I am now using sge6.1, however it doesn't have the option "JOB" for complex >> consumable value. Is there another way to NOT multiply consumable memory >> resource by number of pe slots? > > Not that I'm aware of. It was a features introduced with SGE 6.2u2: > > https://arc.liv.ac.uk/trac/SGE/ticket/197 > > -- Reuti > > >> >> Thanks >> John >> >> >> >> -----Original Message----- >> From: Reuti [mailto:re...@staff.uni-marburg.de] >> Sent: Wednesday, December 21, 2016 7:05 >> To: Christopher Black >> Cc: John_Tai; users@gridengine.org; Coleman, Marcus [JRDUS Non-J&J] >> Subject: Re: [gridengine users] John's cores pe (Was: users Digest...) >> >> >> Am 20.12.2016 um 23:42 schrieb Christopher Black: >> >>> We have found that the behavior that multiples consumable memory resource >>> requests by number of pe slots can be confusing (and requires extra math in >>> automation scripts), so we've have the complex consumable value set to >>> "JOB" rather than "YES". When this is done (at least on SoGE), the memory >>> requested is NOT multiplied by the number of slots. We also use h_vmem >>> rather than virtual_free. >> >> Correct, it's not multiplied. But only the master exechost will get its >> memory reduced in the bookeeping. The slave exechosts might still show a too >> high value of the available memory I fear. >> >> -- Reuti >> >> >>> Best, >>> Chris >>> >>> On 12/20/16, 5:11 AM, "users-boun...@gridengine.org on behalf of Reuti" >>> <users-boun...@gridengine.org on behalf of re...@staff.uni-marburg.de> >>> wrote: >>> >>> >>>> Am 20.12.2016 um 02:45 schrieb John_Tai <john_...@smics.com>: >>>> >>>> I spoke too soon. I can request PE and virtual_free separately, but I >>>> cannot request both: >>>> >>>> >>>> >>>> # qsub -V -b y -cwd -now n -pe cores 7 -l mem=10G -q all.q@ibm037 >>>> xclock >>> >>> Above you request "mem" (which is a snapshot of the actual usage and may >>> vary over the runtime of other jobs [unless they request the total amount >>> already at the beginning of the job and stay with it]). >>> >>>> Your job 180 ("xclock") has been submitted # qstat >>>> job-ID prior name user state submit/start at queue >>>> slots ja-task-ID >>>> ----------------------------------------------------------------------------------------------------------------- >>>> 180 0.55500 xclock johnt qw 12/20/2016 09:43:41 >>>> 7 >>>> # qstat -j 180 >>>> ============================================================== >>>> job_number: 180 >>>> exec_file: job_scripts/180 >>>> submission_time: Tue Dec 20 09:43:41 2016 >>>> owner: johnt >>>> uid: 162 >>>> group: sa >>>> gid: 4563 >>>> sge_o_home: /home/johnt >>>> sge_o_log_name: johnt >>>> sge_o_path: >>>> /home/sge/sge8.1.9-1.el5/bin:/home/sge/sge8.1.9-1.el5/bin/lx-amd64:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin:/home/johnt/bin:. >>>> sge_o_shell: /bin/tcsh >>>> sge_o_workdir: /home/johnt/sge8 >>>> sge_o_host: ibm005 >>>> account: sge >>>> cwd: /home/johnt/sge8 >>>> hard resource_list: virtual_free=10G >>> >>> 10G times 7 = 70 GB >>> >>> The node has this amount of memory installed and it is defined this way in >>> `qconf -me ibm037`? >>> >>> -- Reuti >>> >>> >>>> mail_list: johnt@ibm005 >>>> notify: FALSE >>>> job_name: xclock >>>> jobshare: 0 >>>> hard_queue_list: all.q@ibm037 >>>> env_list: TERM=xterm,DISPLAY=dsls11:3. [..] >>>> script_file: xclock >>>> parallel environment: cores range: 7 >>>> binding: NONE >>>> job_type: binary >>>> scheduling info: cannot run in queue "sim.q" because it is not >>>> contained in its hard queue list (-q) >>>> cannot run in queue "pc.q" because it is not >>>> contained in its hard queue list (-q) >>>> cannot run in PE "cores" because it only >>>> offers 0 slots >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Reuti [mailto:re...@staff.uni-marburg.de] >>>> Sent: Saturday, December 17, 2016 10:16 >>>> To: Reuti >>>> Cc: John_Tai; users@gridengine.org; Coleman, Marcus [JRDUS Non-J&J] >>>> Subject: Re: [gridengine users] John's cores pe (Was: users >>>> Digest...) >>>> >>>> >>>> Am 17.12.2016 um 11:34 schrieb Reuti: >>>> >>>>> >>>>> Am 17.12.2016 um 02:01 schrieb John_Tai: >>>>> >>>>>> It is working!! Thank you to all that replied to me and helped me figure >>>>>> this out. >>>>>> >>>>>> I meant to set the default to 2G so that was my mistake. I changed it to: >>>>>> >>>>>> virtual_free mem MEMORY <= YES YES 2G >>>>>> 0 >>>>> >>>>> That's strange. A plain "2" was for me always two bytes. A "h_vmem" of 2 >>>>> bytes would crash the job instantly when it got scheduled, but for >>>>> "virtual_free" (which is only a guidance for SGE how to distribute jobs) >>>>> it shouldn't hinder the scheduling at all. >>>>> >>>>> `man sge_types` also lists: >>>>> >>>>> If no multiplier is present, the value is just counted in bytes. >>>> >>>> We have set "-w e" in /usr/sge/default/common/sge_request, and then I even >>>> face an "Unable to run job: error: no suitable queues." This happens >>>> whether the low 2 byte value is specified in the complex definition `qconf >>>> -mc` or on the command line as "-l virutal_free=2". >>>> >>>> It turns out, that the minimum value which is being accepted is: 33. >>>> >>>> -- Reuti >>>> >>>> >>>>> >>>>>> And it's working now. Although I'm not sure why it affected the PE. >>>>>> >>>>>> Also I didn't set a global one, what is the purpose of the global one? >>>>>> Should I set it? >>>>> >>>>> No, it was only one place I would have checked too. The global complexes >>>>> therein can for example be used for a limit in the number of licenses of >>>>> an application you have and which can be used floating in the cluster >>>>> (one could prefer to put such a limit in an RQS though). >>>>> >>>>> If you would have set it up there, it would have been the "overall limit >>>>> of memory which can be used in the complete cluster at the same time". >>>>> >>>>> -- Reuti >>>>> >>>>> >>>>>> # qconf -se global >>>>>> hostname global >>>>>> load_scaling NONE >>>>>> complex_values NONE >>>>>> load_values NONE >>>>>> processors 0 >>>>>> user_lists NONE >>>>>> xuser_lists NONE >>>>>> projects NONE >>>>>> xprojects NONE >>>>>> usage_scaling NONE >>>>>> report_variables NONE >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Reuti [mailto:re...@staff.uni-marburg.de] >>>>>> Sent: Friday, December 16, 2016 7:36 >>>>>> To: John_Tai >>>>>> Cc: Christopher Heiny; users@gridengine.org; Coleman, Marcus >>>>>> [JRDUS Non-J&J] >>>>>> Subject: Re: [gridengine users] John's cores pe (Was: users >>>>>> Digest...) >>>>>> >>>>>> >>>>>>> Am 16.12.2016 um 09:53 schrieb John_Tai <john_...@smics.com>: >>>>>>> >>>>>>> virtual_free mem MEMORY <= YES YES 2 >>>>>>> 0 >>>>>> >>>>>> This would mean, that the default consumption is 2 bytes. I already >>>>>> feared that a high values was programmed here. More suitable would be a >>>>>> default of 1G or so. >>>>>> >>>>>> Is there any virtual_free complex defined on a global level: qconf >>>>>> -se global >>>>>> >>>>>> -- Reuti >>>>>> ________________________________ >>>>>> >>>>>> This email (including its attachments, if any) may be confidential and >>>>>> proprietary information of SMIC, and intended only for the use of the >>>>>> named recipient(s) above. Any unauthorized use or disclosure of this >>>>>> email is strictly prohibited. If you are not the intended recipient(s), >>>>>> please notify the sender immediately and delete this email from your >>>>>> computer. >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> users mailing list >>>>> users@gridengine.org >>>>> https://gridengine.org/mailman/listinfo/users >>>> >>>> ________________________________ >>>> >>>> This email (including its attachments, if any) may be confidential and >>>> proprietary information of SMIC, and intended only for the use of the >>>> named recipient(s) above. Any unauthorized use or disclosure of this email >>>> is strictly prohibited. If you are not the intended recipient(s), please >>>> notify the sender immediately and delete this email from your computer. >>>> >>> >>> >>> _______________________________________________ >>> users mailing list >>> users@gridengine.org >>> https://gridengine.org/mailman/listinfo/users >>> >>> >>> >>> This electronic message is intended for the use of the named recipient >>> only, and may contain information that is confidential, privileged or >>> protected from disclosure under applicable law. If you are not the intended >>> recipient, or an employee or agent responsible for delivering this message >>> to the intended recipient, you are hereby notified that any reading, >>> disclosure, dissemination, distribution, copying or use of the contents of >>> this message including any of its attachments is strictly prohibited. If >>> you have received this message in error or are not the named recipient, >>> please notify us immediately by contacting the sender at the electronic >>> mail address noted above, and destroy all copies of this message. Please >>> note, the recipient should check this email and any attachments for the >>> presence of viruses. The organization accepts no liability for any damage >>> caused by any virus transmitted by this email. >>> >> >> ________________________________ >> >> This email (including its attachments, if any) may be confidential and >> proprietary information of SMIC, and intended only for the use of the named >> recipient(s) above. Any unauthorized use or disclosure of this email is >> strictly prohibited. If you are not the intended recipient(s), please notify >> the sender immediately and delete this email from your computer. >> > > ________________________________ > > This email (including its attachments, if any) may be confidential and > proprietary information of SMIC, and intended only for the use of the named > recipient(s) above. Any unauthorized use or disclosure of this email is > strictly prohibited. If you are not the intended recipient(s), please notify > the sender immediately and delete this email from your computer. >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
