dhis2-devs team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

As Lars points out, there are a lot of messages on this archive
related to this issue.

Just a word of caution..I would doubt that it would be a problem with
Postgres, and would caution you if you start to try and optimize the
memory settings beyond what is in the default configuration file.
Tweaking memory settings in Postgres  (if that is what you are using?)
can lead to decreased performance unless you are quite careful and
methodical. But, if you do have posgres logs it would help to see them
as well.



2009/3/20 Lars Helge Øverland <larshelge@xxxxxxxxx>:
>
>
> On Fri, Mar 20, 2009 at 10:14 AM, Thuy Nguyen <thuy.hispvietnam@xxxxxxxxx>
> wrote:
>>
>> Dear all,
>>
>> We HISP Vietnam team meet a problem and need solution to solve. Currently
>> DHIS2 of HISP Vietnam using report module to generate reports which created
>> by BIRT report designer. On the March 19th, 2009 there was a training class
>> for users to practice entering data and generating reports. The class
>> includes 40 users work at same time in the program.
>> Entering data values was fine. But when there are many users generate
>> reports at the same time. The system suddenly become very slow and every
>> user get the OutOfMemorry java exception when click in any button of the
>> program. That time Tri has to restart the tomcat of server, the sistuation
>> become better for 2 minutes, and the problem appear again when few users
>> generate reports. This even affect to another users who doesn't generate
>> report but entering data in the class that time.
>> Tri has checked in database, there were many many transactions opened but
>> weren't closed.
>> After meeting to find the reason, we don't know about other reason except
>> reports were designed by BIRT. May be we were wrong. We are looking forward
>> your suggestions and consult to find out the right reason and solutions to
>> solve. May be change another tool instead of BIRT, or correct the program or
>> someway else. Dr. Trung requested us have to find the right solution before
>> April.
>> Please help us...
>
> Increasing memory for Java/Tomcat  and the database is an option as Jason
> points out. Please check the archives for info on this.
>
> Otherwise, report generation processes are run sequentially and shouldn't
> really give memory problems. A workaround could be to use the "view report
> based on existing datasource" option when viewing the report (after the data
> has been generated once), that is, skipping the aggregation process and view
> the report based on what already exists in the database, should be less
> resource demanding.
>
> Will investigate this further.
>
>
> Lars
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>