Difference between revisions of "ESciDoc Committer Meeting 2010-11-09"

From MPDLMediaWiki
Jump to navigation Jump to search
(New page: Date: 09.22.2010 Start time: '''14:30''' End time: '''15:30''' Location: Karlsruhe, München phone: +49-89-38602-223 VidCo-ISDN: 08938602595; alternate ip 192.129.1.132 Participant...)
 
 
Line 18: Line 18:


=Topics=
=Topics=
==?==
==postgres connections==
 
*since core service 1.2 deployment and the postgres connections, we have had experienced quite unusual memory consumption of postgres. From ca. 10 connections to the database, one of these connections consumes enourmous RAM  and is never set free (4-6 GB). The same behavior is on all servers, even those which are simply set as default and have no midnight fetching of data.
*Note that this process is not the postmaster process itself, but is the escidoc-core connection process to escidoc-core database.Our servers start to consume after a while a lot of swap and then after some time the system stops functioning.The total memory of the server where this is really critical is 32 GB, where postgres database itself uses only 1/4 of it.
*Can you please investigate a bit or let us know if you have some ideas how to monitor this problem?
== others ==
== others ==
*eSciDoc-Colab Page setup
*eSciDoc-Colab Page setup

Latest revision as of 09:38, 8 November 2010

Date: 09.22.2010 Start time: 14:30 End time: 15:30

Location: Karlsruhe, München phone: +49-89-38602-223 VidCo-ISDN: 08938602595; alternate ip 192.129.1.132

Participants MPDL: Natasa Bulatovic, Wilhelm Frank

Participants FIZ: Steffen Wagner, Frank Schwichtenberg, Harald Kappus

Previous committer meeting

Next committer meetings

Topics[edit]

postgres connections[edit]

  • since core service 1.2 deployment and the postgres connections, we have had experienced quite unusual memory consumption of postgres. From ca. 10 connections to the database, one of these connections consumes enourmous RAM and is never set free (4-6 GB). The same behavior is on all servers, even those which are simply set as default and have no midnight fetching of data.
  • Note that this process is not the postmaster process itself, but is the escidoc-core connection process to escidoc-core database.Our servers start to consume after a while a lot of swap and then after some time the system stops functioning.The total memory of the server where this is really critical is 32 GB, where postgres database itself uses only 1/4 of it.
  • Can you please investigate a bit or let us know if you have some ideas how to monitor this problem?

others[edit]

  • eSciDoc-Colab Page setup
  • installation guides