Difference: ReleaseNotes1841 (10 vs. 11)

Revision 112008-08-27 - MarcoCecchi

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

Release notes for Patch #1841

Changed:
<
<
New release (08_98) of the WMS for gLite3.1/SL4. Changes with respect to the current production version:
>
>
Release 08_98 of the WMS for gLite3.1/SL4. Changes with respect to the current production version (patch #1726?):
 
Changed:
<
<
  • Very often, especially under high loads, the virtual memory occupation for the glite-wms-workload_manager process may reach very high values, such as one Gigabyte and more. Despite what one might think at first sight, this is not about a memory leak, but simply the effect of the so called per-thread arenas. The WM in fact, keeps in memory requests and a very large data structure containing up-to-date resource information, the so called information supermarket, which is accessed by several threads. With the linux standard malloc implementation (ptmalloc2) all this data cause the memory to grow large. See tcmalloc for a detailed explanation. Especially wherever RAM is less than or equal to 4Gb, it is highly suggested to workaround this problem using run-time redirection to whatever lock-free, optimized alternative allocator, to avoid excessive swap activity. Here is our recipe which makes use of the TCmalloc, such an alternate allocator distributed by Google under BSD license:
    • after installing the two rpms, google-perftools-devel-???.rpm and google-perftools-???.rpm (whichever version should be fine),
    • you can use tcmalloc this way: export LD_PRELOAD="/usr/lib/libtcmalloc.so" in the glite-wms-wm script. Even if not specifically recommended (actually it may not work with everything) run-time malloc redirection has proven to get well along with the glite workload manager, so that it can be used without any problem in such circumstances.
>
>
  • Enabled submission to CREAM CE. A newly introduced component in the WMS internal architecture, called ICE, implements the job submission service to CREAM. Its functionality can be compared to what the three components JC. LM and CondorG do for the submission to LCG CE
 
Changed:
<
<
  • LDAP queries used to fetch information in the Information Supermarket from the BDII can now be pre-filtered. This is very helpful whenever a WMS instance is dedicated to only one VO. Typically, using a production BDII, the ISM reaches a size of 6-7000 entries, with the consequence that the match-making time for a job can take up to ten seconds. Using the filter on the VO name, as for the mentioned use-case, significantly reduces the times for MM. The filter expression is specified using an environment variable, as shown in this example:
>
>
Important: 1) if the recovery is not enabled, simply starting and stopping the glite-wms-workload_manager process (and of course restarting after whatever kind of crash) might cause duplicating requests. 2) the recovery only works with "JobDir" (see below)
 
Changed:
<
<
  • Temporarily removed the purchasing from CEMon.
>
>
  • "JobDir", the newest mailbox-based persistent communication mechanism between the WM proxy and the WM is now enabled by default. A tool is available for converting from the former mechanism based on filelist (conversion in the opposite way is also supported). At the moment this not done automatically. Of course, one can always think of handling this transition by putting the WMS in drain and wait for the filelist to be empty.
 
Changed:
<
<
  • Added the possibility to submit to a CREAM-CE through a new component called ICE
>
>
  • Modified design to allow DNS load balancing
 
Changed:
<
<
  • DNS load balancing
>
>
  • LDAP queries to fetch information in the Information Supermarket from the BDII can now be pre-filtered. This can be very helpful whenever a WMS instance is dedicated to only one VO. Typically, using a production BDII, the ISM reaches a size of 6-7000 entries, with the consequence that the match-making for a job can take a time of the order of ten seconds. Using the filter on the VO name, as for the aforementioned use-case, significantly reduces the MM time. The filtering expression has to be set using an environment variable, as shown in the following example:
 
Changed:
<
<
  • JobDir as input mechanism to WM in place of FileList. Tool available for conversion. Should it be done automatically? Or would it be better to put the WMS in drain during the transition?
>
>
  • Purchasing from CEMon has been temporarily disabled
 
Changed:
<
<
  • Add recovery procedure for the WM (EnableRecovery = true). Notice: if the recovery is not enabled, starting and stopping the workload_manager might cause duplicating requests.
>
>
  • Purchasing from RGMA has been dismissed
 
Changed:
<
<
  • No more support for RGMA as information system.
>
>
* UpdateRate*
 
Changed:
<
<
  • Deprecated components:
    • checkpointing (glite-wms-checkpointing)
>
>
  • Deprecated??? components:
    • xxxcheckpointing (glite-wms-checkpointing) (already in patch 1726)
 
    • partitioner (glite-wms-partitioner)
    • interactive (glite-wms-interactive and glite-wms-thirdparty-bypass), suggest to use i2glogin with appropriate links
Changed:
<
<
    • rgma (info system)
>
>
  • Known issues:
  • Very often, especially under high loads, the virtual memory occupation for the glite-wms-workload_manager process may reach very high values, such as one Gigabyte and more. This is not about a memory leak, but simply the effect of a well-known problem with the allocator which comes with the glibc (the so called ptmalloc2). See tcmalloc for a more detailed explanation.
This problem can be avoided using run-time redirection to whatever lock-free, optimized alternative allocator, to avoid excessive swap activity. It is highly suggested doing so wherever RAM is less than or equal to 4Gb. Here is our recipe which makes use of the TCmalloc, such an alternate allocator distributed by Google under BSD license: * install the two rpms, google-perftools-devel-???.rpm and google-perftools-???.rpm (just pick up the latest version, older versions should work anyway, just in case), * enable redirection to tcmalloc with: export LD_PRELOAD="/usr/lib/libtcmalloc.so" in the glite-wms-wm script. Even if not specifically recommended (actually it may not work with everything) run-time malloc redirection has proven to get along well with the glite workload manager.
  -- AlessioGianelle - 27 May 2008
 
This site is powered by the TWiki collaboration platformCopyright © 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback