Hervé Piedvache (bill.fo...@gmail.com)

How can I process to find this ? It's a production server for a web service,
and I have no idea how to find wich process was the cause of this ... !?

> You may also consider some other linux configuration options that make
> invocation of OOM killer less likely.

On this server there is only Postgresql, slony, and sshd running the rest is
only Linux basic process (cron, atd, getty etc.)

regards,

Tom,

Le mercredi 09 janvier 2008, Tom Lane a écrit :
> =?utf-8?q?Herv=C3=A9_Piedvache?= <bill.footcow@gmail.com> writes:
> > When I have a lot of connexions (persistante connexions from 6 web
> > apache/php serveurs using PDO, about 110 process on each web servers) on
> > the server, or long request, it's difficult for me to know when it's
> > appening, the kernel seems to kill my postgresql process then the server
> > become completly instable, and most of the time need a reboot ...
>
> Turn off memory overcommit.

My sysctl.conf file looks like this :
kernel.shmmax= 941604096
kernel.sem = 250 32000 100 400
fs.file-max=655360
vm.overcommit_memory=2
vm.overcommit_ratio=30

> > max_connections = 2048
>
> Have you considered using a connection pooler in front of a smaller
> number of backends?

Which system do you recommand for this ?

> If you really need that many backends, it'd likely be a good idea to
> reduce max_files_per_process to perhaps 100 or so. If you manage
> to run the kernel out of filetable slots, all sorts of userland stuff
> is going to get very unhappy.

I'll try this ...

regards,

Log Analyzer : pgFouine
http://pgfoundry.org/projects/pgfouine/

Regards,

Le samedi 29 décembre 2007, Ivan Sergio Borgonovo a écrit :

Hi,

I have a small question ... right now on a 8.1.10 version of PostgreSQL I'm
doing a  vacuum full verbose anaylze a table with 60 304 340 rows in 1155791 
pages and there were 16 835 144 unused item pointers inside and 5 index.

After the first treatment of the index (appeared in the verbose) ... the
vacuum is still working now since 15 hours ... There is none other activity
on this server ... it's a replication server ... so the vacuum is locking
most of the replication queries ...
What can I do to get this doing quicker ...?
It's a 8Gb server ... with a RAID 10 ... my maintenance_work_mem = 25600.

Any idea ?
I'm sure that if I delete all the index an rebuild them by hand it'll be
really quicker ! (done on another replication server ... took 20 min)

regards,

Do you have analyzed your table before doing this ?

Le samedi 28 juillet 2007, Bruno Rodrigues Siqueira a écrit :