[metrics-dev] A Q about metrics

[Lee Liming]

I don't understand the question.  What "big runs" are you referring to?

        -- Lee

On Oct 11, 2006, at 11:06 PM, Ian Foster wrote:

> and what did you learn about where those big runs have been coming  
> from, of late?
>
> Ian.
>
>
> At 07:55 PM 10/11/2006 -0600, Lee Liming wrote:
>> I ran the GridFTP buffer report generator without any special options
>> (heap size change, etc.), and it completed successfully.  Still took
>> a while, but it is nice to see the charts!
>>
>>         -- Lee
>>
>> On Oct 11, 2006, at 1:03 PM, Jarek Gawor wrote:
>>
>>>
>>>> It seems that we might want to look into making the report
>>>> generation
>>>> code more memory efficient.  It's cool that it's highly portable  
>>>> and
>>>> generic for lots of different kinds of reports, but it isn't so  
>>>> cool
>>>> that it requires so much memory.
>>>
>>> I looked at this a bit and the problem is not with the code that
>>> generates
>>> the report but actually with the jdbc driver. The driver by default
>>> tries to
>>> retreive _all_ the results of the query before passing it to the
>>> application. That kills the memory. The report itself uses very
>>> little of
>>> memory.
>>>
>>> To fix this issue:
>>>
>>> 1) Download the following driver:
>>> http://jdbc.postgresql.org/download/pg74.216.jdbc2.jar and put it in
>>> $G_L/lib
>>> 2) Remove the old driver from $G_L/lib (pg73jdbc2.jar)
>>> 3) Update the usage reporting code (do cvs update in usage/java/  
>>> reports) and
>>> deploy it.
>>>
>>> Jarek
> _______________________________________________________________
> Ian Foster -- Weblog: http://ianfoster.typepad.com
> Computation Institute: www.ci.uchicago.edu & www.ci.anl.gov
> Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439
> Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637
> Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org
>
>