8 odpowiedzi na ten temat

[Dżo]

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.

[patryk]

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).

[Dżo]

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.

[patryk]

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.

[pleple]

Zobacz do /proc/bean_counters (jakoś tak się nazywa ten plik w OpenVZ/Virtuozzo, prawdopodobnie powinieneś go mieć).

[bellerofont]

pleple, o 13.01.2008, 21:22, powiedział:

Zobacz do /proc/bean_counters (jakoś tak się nazywa ten plik w OpenVZ/Virtuozzo, prawdopodobnie powinieneś go mieć).

cat /proc/user_beancounters

[Dżo]

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

[pleple]

Dżo, o 13.01.2008, 21:40, powiedział:

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...

[Dżo]

Dziękuję wszystkim za odpowiedzi. Wprowadziłem zmiany w konfiguracji niektórych usług, zobaczymy czy przyniosą efekty.