Re: Too much postmaster prozesses / CPU near 100%
От | Tom Lane |
---|---|
Тема | Re: Too much postmaster prozesses / CPU near 100% |
Дата | |
Msg-id | 14354.1004389841@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Too much postmaster prozesses / CPU near 100% ("Roth, Michael J." <MichaelRoth@schmuecker.de>) |
Список | pgsql-novice |
"Roth, Michael J." <MichaelRoth@schmuecker.de> writes: > After we run the new Server, some hours all things are ok. > And then, suddenly the machine creates many postmaster-processes in > a few seconds. Other System-Functions works now likewise not correct > (top: CPU-Idle 62985,2 %; /etc/init.d/postmaster stop =3D failed; > but /etc/init.d/postmaster start =3D postmaster already running;=20 > "/proc not mounted"; "too many open files in system"; <-- examples) This is just a guess, but --- "too many open files in system" is very suspicious. That means you ran out of kernel filetable slots. Postgres itself tends to hold up fairly well under conditions of no free filetable slots, but almost everything else on a Unix system will go to hell in a handbasket because it's not expecting that error. I wonder whether what happened was that you ran out of filetable slots and then your client software failed because of that, failing in a mode that resulted in spawning lots of additional database connections. It'd be worth increasing the kernel filetable size to see if that alleviates the problem. I forget how to do that on Linux systems, but on other Unixen the kernel parameters NFILE and NINODE need to be increased. It could be that the out-of-filetable-slots condition is a consequence of having too many backends, not its cause ... but in any case it seems clear that you don't have enough filetable slots to support the max number of connections you've told Postgres to accept. You should probably figure on Postgres chewing up 100 or so slots per backend. regards, tom lane
В списке pgsql-novice по дате отправления: