Dżo 0 Zgłoś post Napisano Styczeń 13, 2008 Ostatnimi czasy miewam problemy z bazą danych PostgreSQL (wersja 8.1 z paczki pod Debianem Etch, konfiguracja także z paczki). Wywala się zostawiając w logu następujące informacje: 2008-01-06 01:05:16 CET LOG: could not fork new process for connection: Cannot allocate memory 2008-01-06 01:05:17 CET LOG: could not fork new process for connection: Cannot allocate memory 2008-01-06 01:05:21 CET LOG: could not fork new process for connection: Cannot allocate memory 2008-01-06 01:05:21 CET LOG: could not fork new process for connection: Cannot allocate memory <powyższy komunikat powtórzony jeszcze kilka, kilkanaście razy> 2008-01-06 01:05:33 CET LOG: out of file descriptors: Too many open files in system; release and retry 2008-01-06 01:05:33 CET LOG: out of file descriptors: Too many open files in system; release and retry 2008-01-06 01:05:33 CET LOG: out of file descriptors: Too many open files in system; release and retry 2008-01-06 01:05:33 CET LOG: out of file descriptors: Too many open files in system; release and retry 2008-01-06 01:05:33 CET LOG: out of file descriptors: Too many open files in system; release and retry <także powtórzony wielokrotnie> 2008-01-06 01:05:34 CET LOG: select() failed in postmaster: Cannot allocate memory 2008-01-06 01:05:34 CET FATAL: semctl(720902, 1, SETVAL, 0) failed: Invalid argument Wydawałoby się, że pierwszy komunikat jasno informuje, że w systemie brakuje pamięci. Jednak free -m podaje: total used free shared buffers cached Mem: 2019 1998 21 0 10 987 -/+ buffers/cache: 1001 1018 Swap: 2996 0 2995 Więc pamięci jako takiej jest pod dostatkiem. Wprawdzie cała historia rozgrywa się na VPS-ie z 256 MB gwarantowanej pamięci (max. 700 MB), ale nie wydaje mi się, żeby ten limit był przekroczony. Nie wiem czy jest sens zmniejszać przydział pamięci w konfiguracji PostgreSQL, w końcu w standardowej konfiguracji nie jest tego dużo. Na tym VPS-ie stoi tylko jedna większa strona, która ma ok. 5000 unikalnych gości dziennie. Wcześniej pady bazy zdarzały się rzadko, wyłącznie przy dużym obciążeniu. Ostatnio zdarza się to nawet kilka razy dziennie przy zwykłym obciążeniu. Konfiguracji nie tykałem od dłuższego czasu. Byłbym wdzięczny za sugestie dotyczące rozwiązania problemu. Mam nadzieję, że podałem dość informacji byście mogli zasugerować jakieś rozwiązanie. W razie potrzeby chętnie uzupełnię opis o dodatkowe informacje. Udostępnij ten post Link to postu Udostępnij na innych stronach
patryk 451 Zgłoś post Napisano Styczeń 13, 2008 Wyraźnie w logach widać, że naruszasz limity VPSa - limit otwartych plików w jednym momencie + limit pamięci. Swoją drogą dziwne, że w ofertach VPSów dużych firm nie ma informacji o takich dość znaczących rzeczach jak limicie otwartych plików czy liczbie aktywnych procesów, bo każdy VPS na OpenVZ czy Virutozzo musi mieć coś takiego ustawione (a 90% firm opiera sie o to opgramowanie). Rozwiązanie? Przejście na wyższą opcję lub obcięcie VPSa ze zbędnych usług, które zajmują pamięć i otwierają pliki (chociażby serwer pocztowy). Udostępnij ten post Link to postu Udostępnij na innych stronach
Dżo 0 Zgłoś post Napisano Styczeń 13, 2008 Jeśli w istocie problemem jest brak pamięci lub limit otwartych plików to czemu dotyka to tylko PostgreSQL? Inne usługi i programy działają bez zająknięcia. Udostępnij ten post Link to postu Udostępnij na innych stronach
patryk 451 Zgłoś post Napisano Styczeń 13, 2008 PostgreSQL ma to do siebie, że w domyślnej konfiguracji lubi sobie otworzyć nawet 1000 plików naraz (tempy, bzdety) - zainteresuj sie opcją max_files_per_process, choć manipulowanie nią może się odbić na wydajności. Udostępnij ten post Link to postu Udostępnij na innych stronach
pleple 0 Zgłoś post Napisano Styczeń 13, 2008 Zobacz do /proc/bean_counters (jakoś tak się nazywa ten plik w OpenVZ/Virtuozzo, prawdopodobnie powinieneś go mieć). Udostępnij ten post Link to postu Udostępnij na innych stronach
beliq 442 Zgłoś post Napisano Styczeń 13, 2008 Zobacz do /proc/bean_counters (jakoś tak się nazywa ten plik w OpenVZ/Virtuozzo, prawdopodobnie powinieneś go mieć). cat /proc/user_beancounters Udostępnij ten post Link to postu Udostępnij na innych stronach
Dżo 0 Zgłoś post Napisano Styczeń 13, 2008 Ups... wychodzi na to, że chyba jednak pamięć. failcnt dla przydziałów pamięci jest podejrzanie wysoki. Version: 2.5 uid resource held maxheld barrier limit failcnt 1220162: kmemsize 8931113 9751757 14112433 15523665 6233820 lockedpages 0 0 7600 8192 0 privvmpages 65722 71861 238528 259324 0 shmpages 3853 3853 262144 262144 0 dummy 0 0 0 0 0 numproc 74 80 396 396 0 physpages 47226 51669 0 2147483647 0 vmguarpages 0 0 132062 2147483647 0 oomguarpages 47228 51671 132062 2147483647 0 numtcpsock 30 48 1000 1000 0 numflock 17 21 400 464 0 numpty 6 6 128 128 0 numsiginfo 1 2 1024 1024 0 tcpsndbuf 558164 834028 5366512 8204912 0 tcprcvbuf 453000 672700 5366512 8204912 0 othersockbuf 30416 225560 3006464 8126464 0 dgramrcvbuf 0 5684 480000 524288 0 numothersock 18 25 764 764 0 dcachesize 0 0 5023656 5672656 0 numfile 3287 3486 12864 12864 0 dummy 0 0 0 0 0 dummy 0 0 0 0 0 dummy 0 0 0 0 0 numiptent 14 14 256 256 0 Udostępnij ten post Link to postu Udostępnij na innych stronach
pleple 0 Zgłoś post Napisano Styczeń 13, 2008 Ups... wychodzi na to, że chyba jednak pamięć. Pamięć ale nie chodzi o "zwykły RAM" tylko o tak zwane low-memory a konkretnie o pamięć jądra, która się tam znajduje. Najwyraźniej masz za dużo "dużych" procesów... Udostępnij ten post Link to postu Udostępnij na innych stronach
Dżo 0 Zgłoś post Napisano Styczeń 16, 2008 Dziękuję wszystkim za odpowiedzi. Wprowadziłem zmiany w konfiguracji niektórych usług, zobaczymy czy przyniosą efekty. Udostępnij ten post Link to postu Udostępnij na innych stronach
