Some further progress has been made toward resolving the memory leak problem for the DB stuff There is though still some issue leftm, but at a much lower level than before. Since the browsers works I assume standard code is also ok, But please notify me for problems. Flemming PS On an unrelate issue, we have to find a way to be able to load the crs-node (and cas) in such way that the normal access is not utterly disrupted. This afternoon (EST) a large set of gtr-runs were executing on the crs node. SInce the datadisk data 08 that these jobs used for both reading and writting access to the Brahms user disk was extremely slow- this is of course due to the fact the gtr jobs are i/o limitedd and loading ~2*35 jobs in parellel just exhaust the bandwidth. and the data08 and =brahms/u happens to be on the same server machine. One solution will be to allow only one job per user in the crs-queues if this is possible. This will still give a consideraable thorughput w/o effectlively wasting people time when the user isks are accessed. Another solution is to moved the user disk +www to a server by itself. I find it unreasonable that a normal compile job in a brat subsections takes 10 minutes vs ~ 1 minute under normal cirtumstances. ---------------------------------------------------------------- Flemming Videbaek Physics Department Brookhaven National Laboratory e-mail: videbaek@bnl.gov phone: 631-344-4106 _______________________________________________ Brahms-dev-l mailing list Brahms-dev-l@lists.bnl.gov http://lists.bnl.gov/mailman/listinfo/brahms-dev-lReceived on Mon Apr 19 20:26:19 2004
This archive was generated by hypermail 2.1.8 : Mon Apr 19 2004 - 20:26:46 EDT