Обсуждение: Solaris, Postgresql and Problems
Hi All, I have posted this before, but have not yet got any resolutions on it. I am hoping someone with experience can help me out. I am running Postgresql 7.3.2 on Solaris 5.9. I am trying to increase the number of max connections for postgresql but it but I am having some issue. After reading through some docs and getting some tips from folks on the list, I modified the /etc/system file on my host system and entered the following data: set shmsys:shminfo_shmmax=0x2000000 set shmsys:shminfo_shmmin=1 set shmsys:shminfo_shmmni=256 set shmsys:shminfo_shmseg=256 set semsys:seminfo_semmap=256 set semsys:seminfo_semmni=512 set semsys:seminfo_semmns=512 set semsys:seminfo_semmsl=32 After making this change, and increasing the max number of buffers to 128 and the max number of connections to 64, I rebooted my system. Things come up fine, Postgres seems happy, but shortly after the Postgres server dies or terminates with nothing in logs as to WHY it terminates and it keeps doing so even after I revert back to my original config. The only things that remedies the problem of the server dying without any apparent notice is if I revert back to my original /etc/system file.. Does anybody have any experience with these issues? All I am trying to do is get a few more connections out of my system. I could sure use someone's help. Do I need to re-compile postgresql? TIA, Errol Neal Errol Neal, Systems/Network Administrator eneal@enhtech.com Enhanced Technologies Inc. http://www.enhtech.com 703-924-0301 or 800-368-3249 703-924-0302 Fax
Errol Neal <errol.neal@enhtech.com> writes: > After making this change, and increasing the max number of buffers to > 128 and the max number of connections to 64, I rebooted my > system. Things come up fine, Postgres seems happy, but shortly after > the Postgres server dies or terminates with nothing in logs as to WHY > it terminates and it keeps doing so even after I revert back to my > original config. The only things that remedies the problem of the > server dying without any apparent notice is if I revert back to my > original /etc/system file.. Does anybody have any experience with > these issues? All I am trying to do is get a few more connections out > of my system. I could sure use someone's help. Do I need to re-compile > postgresql? Why don't you run the server under 'truss' to see what is killing it? It it probably dumping core, or trying to, since there is nothing in the logs--check your 'ulimit -c' settings and see if there are any core files hanging around in $PGDATA. -Doug
At 10:02 AM 7/25/2003 -0400, you wrote: >Errol Neal <errol.neal@enhtech.com> writes: > > > After making this change, and increasing the max number of buffers to > > 128 and the max number of connections to 64, I rebooted my > > system. Things come up fine, Postgres seems happy, but shortly after > > the Postgres server dies or terminates with nothing in logs as to WHY > > it terminates and it keeps doing so even after I revert back to my > > original config. The only things that remedies the problem of the > > server dying without any apparent notice is if I revert back to my > > original /etc/system file.. Does anybody have any experience with > > these issues? All I am trying to do is get a few more connections out > > of my system. I could sure use someone's help. Do I need to re-compile > > postgresql? > >Why don't you run the server under 'truss' to see what is killing it? >It it probably dumping core, or trying to, since there is nothing in >the logs--check your 'ulimit -c' settings and see if there are any >core files hanging around in $PGDATA. > >-Doug Actually Doug, it is not even "dying". I used the incorrect word. It is shutting down... Here is a log entry: LOG: fast shutdown request LOG: shutting down LOG: database system is shut down LOG: database system was shut down at 2003-07-25 10:54:57 EDT LOG: checkpoint record is at 0/909710 LOG: redo record is at 0/909710; undo record is at 0/0; shutdown TRUE LOG: next transaction id: 7898764; next oid: 49906 LOG: database system is ready LOG: fast shutdown request LOG: shutting down LOG: database system is shut down That is a few seconds after the system comes back up with even the default amount of connections after I put this in my /etc/system file: * POSTGRESQL SETUP 07/24/03 * optimised for 512 connections *set shmsys:shminfo_shmmax=0x2000000 postgres docs max set shmsys:shminfo_shmmin=1 *set shmsys:shminfo_shmmni=256 wasn't enough for 512 pgsql connections set shmsys:shminfo_shmmni=512 set shmsys:shminfo_shmseg=256 set semsys:seminfo_semmap=256 set semsys:seminfo_semmni=512 set semsys:seminfo_semmsl=32 * set semsys:seminfo_semmns=512 wasn't enough for 512 pgsql connections set semsys:seminfo_semmns=1024 *15/5/03 set shmsys:shminfo_shmmax=939524096 The interesting thing is that only my postgres server is having problems with these settings. I am running sendmail and a few other apps that I've compiled on this system. Why is the server just shutting down? It does not exit with an error or anything like that. Now, I will be the first to admit that I am not a Sun/Solaris genius! Actually, I am more like a novice in some respects. However, I know unix administration. My point in saying that is I don't know if those settings are appropriate for my hardware and memory. Again, I would very much appreciate any help and assistance. Errol Errol Neal, Systems/Network Administrator eneal@enhtech.com Enhanced Technologies Inc. http://www.enhtech.com 703-924-0301 or 800-368-3249 703-924-0302 Fax
Errol Neal <errol.neal@enhtech.com> writes: > At 10:02 AM 7/25/2003 -0400, you wrote: > >Why don't you run the server under 'truss' to see what is killing it? > >It it probably dumping core, or trying to, since there is nothing in > >the logs--check your 'ulimit -c' settings and see if there are any > >core files hanging around in $PGDATA. > > > > > > Actually Doug, it is not even "dying". I used the incorrect word. It > is shutting down... Here is a log entry: > > LOG: fast shutdown request This means *something* is sending a SIGTERM to the postmaster. Again, try running it under 'truss' and see what it's doing right before it gets the signal. -Doug
Errol Neal wrote: > > > > Actually Doug, it is not even "dying". I used the incorrect word. It > is shutting down... Here is a log entry: > > LOG: fast shutdown request > LOG: shutting down > LOG: database system is shut down > LOG: database system was shut down at 2003-07-25 10:54:57 EDT > LOG: checkpoint record is at 0/909710 > LOG: redo record is at 0/909710; undo record is at 0/0; shutdown TRUE > LOG: next transaction id: 7898764; next oid: 49906 > LOG: database system is ready > LOG: fast shutdown request > LOG: shutting down > LOG: database system is shut down > I've ever met problem alike in solaris 8, and it turns out as Tom suggested that it's the ctrl-c (SIGTERM) causes the problem. If I'm not guessed worng, may be you are using the command 'tail -f yourlogfile' to see your log after the server start up, and then ctrl-c to quit the 'tail', but the signal would send to postmaster also and cause it shutdown. If so, I'll recommend the precedure below to circumvent the problem: 1, login postgresql superuser accound; 2, start postgresql (nohup pg_ctl start blah, blah); 3, exit login 4, re-login with postgresql superuser and 'tail -f yourlogfile' to monitor it. but I still searching the reason why solaris would act like that Don't know if it helps. regards Laser
I don't remember if I mentioned this or not on this thread, but Solaris pfiles and other similar tools sometimes send wierd signals to processes. You might check your cron tabs to see if something like this is being run on a regular basis. Jon On Fri, 25 Jul 2003, Weiping He wrote: > Errol Neal wrote: > > > > > > > > > Actually Doug, it is not even "dying". I used the incorrect word. It > > is shutting down... Here is a log entry: > > > > LOG: fast shutdown request > > LOG: shutting down > > LOG: database system is shut down > > LOG: database system was shut down at 2003-07-25 10:54:57 EDT > > LOG: checkpoint record is at 0/909710 > > LOG: redo record is at 0/909710; undo record is at 0/0; shutdown TRUE > > LOG: next transaction id: 7898764; next oid: 49906 > > LOG: database system is ready > > LOG: fast shutdown request > > LOG: shutting down > > LOG: database system is shut down > > > I've ever met problem alike in solaris 8, and it turns out as Tom suggested > that it's the ctrl-c (SIGTERM) causes the problem. If I'm not guessed worng, > may be you are using the command 'tail -f yourlogfile' to see your log after > the server start up, and then ctrl-c to quit the 'tail', but the signal > would send > to postmaster also and cause it shutdown. > > If so, I'll recommend the precedure below to circumvent the problem: > > 1, login postgresql superuser accound; > 2, start postgresql (nohup pg_ctl start blah, blah); > 3, exit login > 4, re-login with postgresql superuser and 'tail -f yourlogfile' to > monitor it. > > but I still searching the reason why solaris would act like that > > Don't know if it helps. > > > regards > > Laser > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org >
On Friday, July 25, 2003, at 10:15 AM, Doug McNaught wrote: > This means *something* is sending a SIGTERM to the postmaster. Again, > try running it under 'truss' and see what it's doing right before it > gets the signal. Also, make sure you are starting it in a way that you can _see_ the error. Use something like postmaster -D /usr/local/pgsql/data If you are using a startup script or something similar, you may not see the error in your terminal. I often have this problem after changing system settings. Cory 'G' Watson http://www.loggerithim.org
At 11:34 PM 7/25/2003 +0800, Weiping He wrote: >Errol Neal wrote: > >> >> >> >>Actually Doug, it is not even "dying". I used the incorrect word. It is >>shutting down... Here is a log entry: >> >>LOG: fast shutdown request >>LOG: shutting down >>LOG: database system is shut down >>LOG: database system was shut down at 2003-07-25 10:54:57 EDT >>LOG: checkpoint record is at 0/909710 >>LOG: redo record is at 0/909710; undo record is at 0/0; shutdown TRUE >>LOG: next transaction id: 7898764; next oid: 49906 >>LOG: database system is ready >>LOG: fast shutdown request >>LOG: shutting down >>LOG: database system is shut down >I've ever met problem alike in solaris 8, and it turns out as Tom suggested >that it's the ctrl-c (SIGTERM) causes the problem. If I'm not guessed worng, >may be you are using the command 'tail -f yourlogfile' to see your log after >the server start up, and then ctrl-c to quit the 'tail', but the signal >would send >to postmaster also and cause it shutdown. > >If so, I'll recommend the precedure below to circumvent the problem: > >1, login postgresql superuser accound; >2, start postgresql (nohup pg_ctl start blah, blah); >3, exit login >4, re-login with postgresql superuser and 'tail -f yourlogfile' to monitor it. > >but I still searching the reason why solaris would act like that > >Don't know if it helps. > > >regards > >Laser > > > > >---------------------------(end of broadcast)--------------------------- >TIP 6: Have you searched our list archives? > > http://archives.postgresql.org That is amazing.. It does it every time. But the funny thing is, it does not do that using the default /etc/system settings. I tail log files all the time and exit them with a ctrl-c. Postgres never interprets that as a signal for it to exit... neither do any of my other processes running.. Errol Neal, Systems/Network Administrator eneal@enhtech.com Enhanced Technologies Inc. http://www.enhtech.com 703-924-0301 or 800-368-3249 703-924-0302 Fax
On Fri, 2003-07-25 at 11:35, Errol Neal wrote: > At 11:34 PM 7/25/2003 +0800, Weiping He wrote: > >Errol Neal wrote: [snip] > > That is amazing.. It does it every time. But the funny thing is, it does > not do that using the default /etc/system settings. I tail log files all > the time and exit them with a ctrl-c. Postgres never interprets that as a > signal for it to exit... neither do any of my other processes running.. Or you could dump that chicken-poop Slowlaris and go with The Real Man's OS: Windows 2k3!!!!! Whaaa hahahahahahahahahahah! ROTFLMAO <snort><gurgle><choke><die> -- +-----------------------------------------------------------------+ | Ron Johnson, Jr. Home: ron.l.johnson@cox.net | | Jefferson, LA USA | | | | "I'm not a vegetarian because I love animals, I'm a vegetarian | | because I hate vegetables!" | | unknown | +-----------------------------------------------------------------+
| After making this change, and increasing the max number of buffers to | 128 and the max number of connections to 64, I rebooted my system. | Things come up fine, Postgres seems happy, but shortly after the | Postgres server dies or terminates with nothing in logs as to WHY it | terminates and it keeps doing so even after I revert back to I've been running Postgres on Solaris x86 (5.8 & 5.9) for several years now and there's a few system level problems with Solaris' shared memory. The shmmax you can set to almost any number without issue. But the others, Solaris will produce kernel panics if the numbers are set too high. I'd recommend only changing shminfo_shmmax at the start. (And make it a larger number while you're at it. 128 shared_buffers is a grand total of 1MB of memory; Postgres will run dog slow at that setting. My servers use settings of 16,000 for 512MB machines to 250,000 for 8GB machines.) 64 connections should not be a problem with the default Solaris shared memory settings (at least not as far as I can remember). If it does complain, then change only the variable the Postgres logs mention.