Thread: postgres dying
Hi all,
Please pardon me if it sound naive or its been answered.
I am running freeradius with postgresql for VOIP with
Cisco gateways. But my server keeps dying and after tuning
the SHMMX and number of connections and all that i still
get the same results.
Any form of help will be greatly appreciated.
Thank you.
System: Fedora 3
CPU : 3GHZ pentium(IV)
RAM : 2GB
HDD : 3 35GB hardisks
Freeradius: freeradius-1.0.1-1
Postgresql: postgresql-7.4.6-1.FC3.1
Postgresql.conf:
================
tcpip_socket = true
max_connections = 180
# note: increasing max_connections costs about
500 bytes of shared
# memory per connection slot, in addition to
costs from shared_buffers
# and max_locks_per_transaction.
superuser_reserved_connections = 4
#---------------------------------------------------------------------------
# RESOURCE USAGE (except WAL)
#---------------------------------------------------------------------------
# - Memory -
#Set to 256MB
shared_buffers = 24000 # min 16, at least
max_connections*2, 8KB each
sort_mem = 32168 # min 64, size in KB
#vacuum_mem = 8192 # min 1024, size in KB
# - Free Space Map -
#max_fsm_pages = 20000 # min
max_fsm_relations*16, 6 bytes each
#max_fsm_relations = 1000 # min 100, ~50 bytes each
# - Kernel Resource Usage -
#max_files_per_process = 1000 # min 25
#preload_libraries = ''
===================================== END ============
Hi Callis, It would be great to understand how it is dying. Note that you've just said that it keeps dying, but you haven't explained us "how is it dying". Therefore, are you able to explain us how / when is it dying? Let me know if I am not clear on my request :) Best wishes, Guido. On 6/5/06, Callis <callis@idncafe.com> wrote: > Hi all, > > Please pardon me if it sound naive or its been answered. > I am running freeradius with postgresql for VOIP with > Cisco gateways. But my server keeps dying and after tuning > the SHMMX and number of connections and all that i still > get the same results. > > Any form of help will be greatly appreciated. > > Thank you. > > System: Fedora 3 > CPU : 3GHZ pentium(IV) > RAM : 2GB > HDD : 3 35GB hardisks > Freeradius: freeradius-1.0.1-1 > Postgresql: postgresql-7.4.6-1.FC3.1 > > Postgresql.conf: > ================ > tcpip_socket = true > max_connections = 180 > # note: increasing max_connections costs about > 500 bytes of shared > # memory per connection slot, in addition to > costs from shared_buffers > # and max_locks_per_transaction. > superuser_reserved_connections = 4 > > > #--------------------------------------------------------------------------- > # RESOURCE USAGE (except WAL) > #--------------------------------------------------------------------------- > > # - Memory - > > #Set to 256MB > shared_buffers = 24000 # min 16, at least > max_connections*2, 8KB each > > sort_mem = 32168 # min 64, size in KB > #vacuum_mem = 8192 # min 1024, size in KB > > # - Free Space Map - > > #max_fsm_pages = 20000 # min > max_fsm_relations*16, 6 bytes each > #max_fsm_relations = 1000 # min 100, ~50 bytes each > > # - Kernel Resource Usage - > > #max_files_per_process = 1000 # min 25 > #preload_libraries = '' > ===================================== END ============ > > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match > -- Guido Barosio ----------------------- http://www.globant.com guido.barosio@globant.com
On Mon, 2006-06-05 at 12:03, Callis wrote: > Hi all, > > Please pardon me if it sound naive or its been answered. > I am running freeradius with postgresql for VOIP with > Cisco gateways. But my server keeps dying and after tuning > the SHMMX and number of connections and all that i still > get the same results. > > Any form of help will be greatly appreciated. > > Thank you. Most of the time this happens, PostgreSQL isn't dying so much as being euthanized by the OS for some reason. Perhaps you're hitting the oom killer in the linux kernel, or you're running it under a ulimit that results in it being killed. If it is dying, is there anything in the postgresql logs showing why it died? Generally speaking, if the database starts up, the shmmax settings and such are fine, as they are not particularly dynamic in their allocation.
Scott Marlowe <smarlowe@g2switchworks.com> writes:
> If it is dying, is there anything in the postgresql logs showing why it
> died?
And if not there, look in the kernel log. If it is an OOM-kill problem
then the kernel log will record the dastardly deed.
regards, tom lane
"Guido Barosio" <gbarosio@gmail.com> wrote: >Hi Callis, > > It would be great to understand how it is dying. Note >that you've >just said that it keeps dying, but you haven't explained >us "how is it >dying". > > Therefore, are you able to explain us how / when is it >dying? This the error message i have in my logs ===== START Jun 6 06:12:45 Billing postgres[2296]: [1-1] FATAL: XX000: could not create shared memory segment: Invalid argument Jun 6 06:12:45 Billing postgres[2296]: [1-2] DETAIL: Failed system call was shmget(key=5432001, size=202776576, 03600). Jun 6 06:12:45 Billing postgres[2296]: [1-3] HINT: This error usually means that PostgreSQL's request for a shared memory segmen t exceeded your kernel's SHMMAX parameter. Jun 6 06:12:45 Billing postgres[2296]: [1-4] You can either reduce the request size or reconfigure the kernel with larger SHMMAX . To reduce the request size (currently Jun 6 06:12:45 Billing postgres[2296]: [1-5] 202776576 bytes), reduce PostgreSQL's shared_buffers parameter (currently 24000) an d/or its max_connections parameter Jun 6 06:12:45 Billing postgres[2296]: [1-6] (currently 180). Jun 6 06:12:45 Billing postgres[2296]: [1-7] If the request size is already small, it's possible that it is less than your kern el's SHMMIN parameter, in which case raising Jun 6 06:12:45 Billing postgres[2296]: [1-8] the request size or reconfiguring SHMMIN is called for. ======= END >Let >me know if I am not clear on my request :) > >Best wishes, >Guido. > > >On 6/5/06, Callis <callis@idncafe.com> wrote: >>Hi all, >> >> Please pardon me if it sound naive or its been answered. >>I am running freeradius with postgresql for VOIP with >>Cisco gateways. But my server keeps dying and after >>tuning >>the SHMMX and number of connections and all that i still >>get the same results. >> >>Any form of help will be greatly appreciated. >> >>Thank you. >> >>System: Fedora 3 >>CPU : 3GHZ pentium(IV) >>RAM : 2GB >>HDD : 3 35GB hardisks >>Freeradius: freeradius-1.0.1-1 >>Postgresql: postgresql-7.4.6-1.FC3.1 >> >>Postgresql.conf: >>================ >>tcpip_socket = true >>max_connections = 180 >> # note: increasing max_connections costs about >>500 bytes of shared >> # memory per connection slot, in addition to >>costs from shared_buffers >> # and max_locks_per_transaction. >>superuser_reserved_connections = 4 >> >> >>#--------------------------------------------------------------------------- >># RESOURCE USAGE (except WAL) >>#--------------------------------------------------------------------------- >> >># - Memory - >> >>#Set to 256MB >>shared_buffers = 24000 # min 16, at least >>max_connections*2, 8KB each >> >>sort_mem = 32168 # min 64, size in KB >>#vacuum_mem = 8192 # min 1024, size in KB >> >># - Free Space Map - >> >>#max_fsm_pages = 20000 # min >>max_fsm_relations*16, 6 bytes each >>#max_fsm_relations = 1000 # min 100, ~50 bytes each >> >># - Kernel Resource Usage - >> >>#max_files_per_process = 1000 # min 25 >>#preload_libraries = '' >>===================================== END ============ >> >> >>---------------------------(end of >>broadcast)--------------------------- >>TIP 9: In versions below 8.0, the planner will ignore >>your desire to >> choose an index scan if your joining column's >>datatypes do not >> match >> > > >-- >Guido Barosio >----------------------- >http://www.globant.com >guido.barosio@globant.com
Callis wrote: > Jun 6 06:12:45 Billing postgres[2296]: [1-4] You can > either reduce the request size or reconfigure the kernel > with larger SHMMAX So did you try to increase the kernel's SHMMAX? -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
On Tue, 6 Jun 2006 09:24:13 -0400 Alvaro Herrera <alvherre@commandprompt.com> wrote: >Callis wrote: > >> Jun 6 06:12:45 Billing postgres[2296]: [1-4] You can >> either reduce the request size or reconfigure the kernel >> with larger SHMMAX > >So did you try to increase the kernel's SHMMAX? Yes, i have but i still have the same error. SHMMAX has been set to 671088640. Any more hints? Thank you. > >-- >Alvaro Herrera > http://www.CommandPrompt.com/ >The PostgreSQL Company - Command Prompt, Inc.