Mam serwer Linux, na którym działa nasz system tworzenia kopii zapasowych bacula. Maszyna szlifuje jak szalona, ponieważ ciężko się wymienia. Problem polega na tym, że wykorzystuje tylko 60% pamięci fizycznej!
Oto dane wyjściowe z free -m:
free -m
total used free shared buffers cached
Mem: 3949 2356 1593 0 0 1
-/+ buffers/cache: 2354 1595
Swap: 7629 1804 5824
i niektóre przykładowe dane wyjściowe z vmstat 1:
procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 2 1843536 1634512 0 4188 54 13 2524 666 2 1 1 1 89 9 0
1 11 1845916 1640724 0 388 2700 4816 221880 4879 14409 170721 4 3 63 30 0
0 9 1846096 1643952 0 0 4956 756 174832 804 12357 159306 3 4 63 30 0
0 11 1846104 1643532 0 0 4916 540 174320 580 10609 139960 3 4 64 29 0
0 4 1846084 1640272 0 2336 4080 524 140408 548 9331 118287 3 4 63 30 0
0 8 1846104 1642096 0 1488 2940 432 102516 457 7023 82230 2 4 65 29 0
0 5 1846104 1642268 0 1276 3704 452 126520 452 9494 119612 3 5 65 27 0
3 12 1846104 1641528 0 328 6092 608 187776 636 8269 113059 4 3 64 29 0
2 2 1846084 1640960 0 724 5948 0 111480 0 7751 116370 4 4 63 29 0
0 4 1846100 1641484 0 404 4144 1476 125760 1500 10668 105358 2 3 71 25 0
0 13 1846104 1641932 0 0 5872 828 153808 840 10518 128447 3 4 70 22 0
0 8 1846096 1639172 0 3164 3556 556 74884 580 5082 65362 2 2 73 23 0
1 4 1846080 1638676 0 396 4512 28 50928 44 2672 38277 2 2 80 16 0
0 3 1846080 1628808 0 7132 2636 0 28004 8 1358 14090 0 1 78 20 0
0 2 1844728 1618552 0 11140 7680 0 12740 8 763 2245 0 0 82 18 0
0 2 1837764 1532056 0 101504 2952 0 95644 24 802 3817 0 1 87 12 0
0 11 1842092 1633324 0 4416 1748 10900 143144 11024 6279 134442 3 3 70 24 0
2 6 1846104 1642756 0 0 4768 468 78752 468 4672 60141 2 2 76 20 0
1 12 1846104 1640792 0 236 4752 440 140712 464 7614 99593 3 5 58 34 0
0 3 1846084 1630368 0 6316 5104 0 20336 0 1703 22424 1 1 72 26 0
2 17 1846104 1638332 0 3168 4080 1720 211960 1744 11977 155886 3 4 65 28 0
1 10 1846104 1640800 0 132 4488 556 126016 584 8016 106368 3 4 63 29 0
0 14 1846104 1639740 0 2248 3436 428 114188 452 7030 92418 3 3 59 35 0
1 6 1846096 1639504 0 1932 5500 436 141412 460 8261 112210 4 4 63 29 0
0 10 1846104 1640164 0 3052 4028 448 147684 472 7366 109554 4 4 61 30 0
0 10 1846100 1641040 0 2332 4952 632 147452 664 8767 118384 3 4 63 30 0
4 8 1846084 1641092 0 664 4948 276 152264 292 6448 98813 5 5 62 28 0
Co więcej, wyjście top posortowane według czasu procesora wydaje się potwierdzać teorię, że swap jest tym, co wpada w system:
top - 09:05:32 up 37 days, 23:24, 1 user, load average: 9.75, 8.24, 7.12
Tasks: 173 total, 1 running, 172 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.6%us, 1.4%sy, 0.0%ni, 76.1%id, 20.6%wa, 0.1%hi, 0.2%si, 0.0%st
Mem: 4044632k total, 2405628k used, 1639004k free, 0k buffers
Swap: 7812492k total, 1851852k used, 5960640k free, 436k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ TIME COMMAND
4174 root 17 0 63156 176 56 S 8 0.0 2138:52 35,38 bacula-fd
4185 root 17 0 63352 284 104 S 6 0.0 1709:25 28,29 bacula-sd
240 root 15 0 0 0 0 D 3 0.0 831:55.19 831:55 kswapd0
2852 root 10 -5 0 0 0 S 1 0.0 126:35.59 126:35 xfsbufd
2849 root 10 -5 0 0 0 S 0 0.0 119:50.94 119:50 xfsbufd
1364 root 10 -5 0 0 0 S 0 0.0 117:05.39 117:05 xfsbufd
21 root 10 -5 0 0 0 S 1 0.0 48:03.44 48:03 events/3
6940 postgres 16 0 43596 8 8 S 0 0.0 46:50.35 46:50 postmaster
1342 root 10 -5 0 0 0 S 0 0.0 23:14.34 23:14 xfsdatad/4
5415 root 17 0 1770m 108 48 S 0 0.0 15:03.74 15:03 bacula-dir
23 root 10 -5 0 0 0 S 0 0.0 13:09.71 13:09 events/5
5604 root 17 0 1216m 500 200 S 0 0.0 12:38.20 12:38 java
5552 root 16 0 1194m 580 248 S 0 0.0 11:58.00 11:58 java
Oto to samo posortowane według rozmiaru obrazu pamięci wirtualnej:
top - 09:08:32 up 37 days, 23:27, 1 user, load average: 8.43, 8.26, 7.32
Tasks: 173 total, 1 running, 172 sleeping, 0 stopped, 0 zombie
Cpu(s): 3.6%us, 3.4%sy, 0.0%ni, 62.2%id, 30.2%wa, 0.2%hi, 0.3%si, 0.0%st
Mem: 4044632k total, 2404212k used, 1640420k free, 0k buffers
Swap: 7812492k total, 1852548k used, 5959944k free, 100k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ TIME COMMAND
5415 root 17 0 1770m 56 44 S 0 0.0 15:03.78 15:03 bacula-dir
5604 root 17 0 1216m 492 200 S 0 0.0 12:38.30 12:38 java
5552 root 16 0 1194m 476 200 S 0 0.0 11:58.20 11:58 java
4598 root 16 0 117m 44 44 S 0 0.0 0:13.37 0:13 eventmond
9614 gdm 16 0 93188 0 0 S 0 0.0 0:00.30 0:00 gdmgreeter
5527 root 17 0 78716 0 0 S 0 0.0 0:00.30 0:00 gdm
4185 root 17 0 63352 284 104 S 20 0.0 1709:52 28,29 bacula-sd
4174 root 17 0 63156 208 88 S 24 0.0 2139:25 35,39 bacula-fd
10849 postgres 18 0 54740 216 108 D 0 0.0 0:31.40 0:31 postmaster
6661 postgres 17 0 49432 0 0 S 0 0.0 0:03.50 0:03 postmaster
5507 root 15 0 47980 0 0 S 0 0.0 0:00.00 0:00 gdm
6940 postgres 16 0 43596 16 16 S 0 0.0 46:51.39 46:51 postmaster
5304 postgres 16 0 40580 132 88 S 0 0.0 6:21.79 6:21 postmaster
5301 postgres 17 0 40448 24 24 S 0 0.0 0:32.17 0:32 postmaster
11280 root 16 0 40288 28 28 S 0 0.0 0:00.11 0:00 sshd
5534 root 17 0 37580 0 0 S 0 0.0 0:56.18 0:56 X
30870 root 30 15 31668 28 28 S 0 0.0 1:13.38 1:13 snmpd
5305 postgres 17 0 30628 16 16 S 0 0.0 0:11.60 0:11 postmaster
27403 postfix 17 0 30248 0 0 S 0 0.0 0:02.76 0:02 qmgr
10815 postfix 15 0 30208 16 16 S 0 0.0 0:00.02 0:00 pickup
5306 postgres 16 0 29760 20 20 S 0 0.0 0:52.89 0:52 postmaster
5302 postgres 17 0 29628 64 32 S 0 0.0 1:00.64 1:00 postmaster
Próbowałem dostrajać swappinessparametr jądra zarówno do wysokich, jak i niskich wartości, ale nic nie wydaje się zmieniać tutaj zachowania. Nie wiem, co się dzieje. Jak mogę dowiedzieć się, co to powoduje?
Aktualizacja: System jest w pełni 64-bitowy, więc nie powinno być mowy o ograniczeniach pamięci z powodu problemów 32-bitowych.
Aktualizacja 2: Jak wspomniałem w pierwotnym pytaniu, próbowałem już dostroić swapiness do różnego rodzaju wartości, w tym 0. Wynik jest zawsze taki sam, a około 1,6 GB pamięci pozostaje nieużywane.
Aktualizacja 3: Dodano górne wyjście do powyższych informacji.
Odpowiedzi:
Wydajność Bacula jest wysoce zależna od bazy danych. Prawdopodobnie to postgresql zabija twój serwer. Wysoka średnia obciążalność i dość duży procent czasu procesora spędzonego w stanie oczekiwania wyraźnie pokazują, że czeka on na We / Wy dysku ... I to robi PostgreSQL. Dla każdego pliku w kopii zapasowej ustaw co najmniej instrukcję UPDATE. Nie martw się o zamianie.
Dostosuj instalację PostgreSQL. Ewentualnie daj poszczególnej bazie danych (lub nawet tabelom) własne dyski / zestawy rajdowe, aby rozłożyć we / wy. Możesz zmusić PostgreSQL do korzystania z zapisów aynschronicznych, jeśli jeszcze tego nie zrobiono ... Mimo to integralność bazy danych w celu zwiększenia wydajności zapisu. Zwiększ piekło ze wspólnej pamięci dostępnej dla PostgreSQL. To złagodzi przynajmniej dużo odczytu w bazie danych. Jeśli nigdy tego nie robiłeś, uruchom VACCUM ANALYZE w bazie danych Bacula, aby dać optymalizatorowi zapytań coś do pracy.
Zdecydowanie najsłabszym punktem Baculi jest zależność bazy danych (i mózg niektórych z nich ...) Wykonaj czyszczenie ostatniej dużej kopii zapasowej i zauważ, ile czasu (często godzin) zajmuje uruchomienie kilkudziesięciu milionów zapytań. .. Bacula lubi stosunkowo niewiele dużych plików, w przeciwnym razie jest to pies.
źródło
Jesteś związany we / wy. Twój system to mała tratwa ratunkowa, poobijana w burzliwym morzu buforów / pamięci podręcznej / falowania stronicowania maszyn wirtualnych o wysokości 100 stóp.
Łał. Po prostu ... wow. Przenosisz około 100 Mb / s poza swoje I / O, jesteś daleko poza 50% czasem procesora w I / O i masz 4 GB pamięci RAM. Ciśnienie wsteczne na maszynie wirtualnej tego serwera musi być ogromne. W „normalnych” okolicznościach, gdy system zaczyna buforować / buforować, dowolna wolna pamięć RAM zostanie zjedzona żywcem w mniej niż 40 sekund .
Możliwe byłoby odpowiedzieć na ustawienia z
/proc/sys/vm? Zapewni to pewien wgląd w to, co twoje jądro uważa za „normalne”.Te
postmasterprocesy wskazują również, że korzystasz z PostgreSQL w tle. Czy to normalne w twojej konfiguracji? PostgreSQL w domyślnej konfiguracji zużywa bardzo mało pamięci RAM, ale gdy zostanie ponownie dostrojony pod kątem szybkości, może szybko zużyć 25% -40% dostępnej pamięci RAM. Mogę tylko zgadywać, biorąc pod uwagę ich liczbę w danych wyjściowych, podczas tworzenia kopii zapasowych uruchamiasz jakąś produkcyjną bazę danych. To nie wróży dobrze. Czy możesz podać więcej informacji o tym, dlaczego działa? Jaki jest rozmiar parametru pamięci współdzielonej dla wszystkichpostmasterprocesy? Czy można by zamknąć usługę lub tymczasowo zmienić konfigurację bazy danych, aby używała mniej połączeń / buforów podczas działania kopii zapasowych? Pomoże to zmniejszyć presję na już napięte wejścia / wyjścia i wolną pamięć RAM. Należy pamiętać, że każdypostmasterproces zużywa pamięć RAM ponad to, co baza danych wykorzystuje do wewnętrznego buforowania. Kiedy więc dostosowujesz ustawienia pamięci, uważaj, które są „współdzielone”, a które „na proces” .Jeśli używasz PostgreSQL jako części procesu tworzenia kopii zapasowej, spróbuj go dostroić, aby akceptować minimalną liczbę połączeń i pamiętaj o zmniejszeniu parametrów poszczególnych procesów do rozsądnego poziomu (tylko kilka megapikseli). Wadą tego jest to, że PostgreSQL wyleje się na dysk, jeśli nie będzie mógł pracować z zestawem danych w pamięci RAM tak, jak chce, więc faktycznie zwiększy to ilość operacji we / wy na dysku , więc nastrój ostrożnie.
X11 sam w sobie nie zajmuje dużo pamięci, ale pełna sesja pulpitu może zużywać kilka megabajtów. Wyloguj się z wszelkich aktywnych sesji i uruchom połączenie z konsoli lub poprzez SSH.
Mimo to nie sądzę, że jest to całkowicie problem z pamięcią. Jeśli masz więcej niż 50% czasu we / wy, czekając przez dłuższy czas (i publikujesz dane dotykające lat 70.), powstałe wąskie gardło ostatecznie zniszczy resztę systemu. Podobnie jak Darth Vader miażdży szyje.
Na ile wątków spłukiwania jesteś skonfigurowany? Posługiwać się
dowiedzieć się i
ustawić go jako pojedynczy wątek. Zauważ, że ostatnie polecenie powoduje, że ładuje się ono na stałe po ponownym uruchomieniu. Widząc tam 1 lub 2 nie jest niczym niezwykłym. Jeśli masz kilka rdzeni lub wiele pojemności wrzeciona / magistrali dla I / O, będziesz chciał je podnieść (nieco). Więcej wątków opróżniania = większa aktywność we / wy, ale także więcej czasu procesora spędzonego w oczekiwaniu na we / wy.
Czy jest to wartość domyślna, czy też ją podbiłeś? Jeśli go zderzyłeś, czy zastanawiałeś się nad zmniejszeniem liczby, aby zmniejszyć presję na operacje we / wy? A może masz ogromną liczbę wrzecion i kanałów do pracy, w takim przypadku, czy zastanawiałeś się nad zwiększeniem liczby nici do spłukiwania?
PS chcesz ustawić swapiness na niższe wartości, a nie na wyższe, aby zapobiec zamianie. Najwyższa wartość = 100 = zamień jak szalony, kiedy wydaje się to właściwe, najniższa wartość = 0 = spróbuj w ogóle nie zamieniać.
źródło
Jeśli spojrzysz na bloki odczytywane na sekundę (bi) pod IO, zmniejsza to aktywność zamiany o wiele rzędów wielkości. Nie sądzę, aby korzystanie z wymiany powodowało bicie dysku, myślę, że masz coś uruchomionego na pudełku, co po prostu powoduje dużą aktywność dysku (odczyty).
Sprawdzę działające aplikacje i sprawdzę, czy możesz znaleźć winowajcę.
źródło
Sprawdź, czy ten link odpowiada na niektóre pytania. Regularnie widzę stronicowanie Linuksa (nie zamianę) pamięci na długo przed wykorzystaniem 60%. Jest to oczekiwany fragment dostrajania pamięci:
http://www.sheepguardingllama.com/?p=2252
Ale martwi mnie twój brak buforów / pamięci podręcznej. To wygląda bardzo nietypowo. Więc myślę, że coś więcej jest nie tak.
źródło
Czy możesz spróbować całkowicie wyłączyć swap?
lub jakieś inne - przynajmniej to potwierdzi, że zamiana jest twoim problemem, a nie czymś innym.
źródło
Domyślnie zamiana jest ustawiona na 60.
cat / proc / sys / vm / swappiness 60
Swappiness to jądro używane do dostrajania, jak bardzo jądro preferuje zamianę pamięci RAM; wysoka zamiana oznacza, że jądro będzie dużo wymieniać, a niska zamiana oznacza, że jądro będzie próbowało nie używać przestrzeni wymiany.
Możemy zmienić tę edycję na wartość vm.swappiness w /etc/sysctl.conf .
źródło
/proc/sys/vm/swappiness.Możesz ręcznie ustawić swapinness jądra, które możesz zobaczyć na
/proc/sys/vm/swappinesslub wydać poleceniesysctl vm.swappiness. Swapiness to ustawienie jądra, które określa, ile zużywa się swap.Poprzez ustawienie
sudo sysctl vm.swappiness=0skutecznie dezaktywujesz partycję wymiany. Aby wprowadzić tę zmianę na stałe, możesz dodać / zmodyfikowaćvm.swappiness=0w/etc/sysctl.conf. Powinieneś zobaczyć, co jest dla ciebie dobrą wartością. Osobiście mam to skonfigurowanevm.swappiness=10, ponieważ jest to wartość domyślna 60.źródło
Inną rzeczą, na którą warto spojrzeć, jest kolejka uruchomieniowa jądra, a nieprzerwane procesy (kolumny „r” i „b” w vmstat) wskazują, że system jest czasami nasycony. Na marginesie, nie myl nasycenia z wykorzystaniem ... prawdziwym problemem może być głodny stos procesów w stosunku do nasyconego jądra :-(
Możesz także uruchomić „pmap -x [PID]”, aby uzyskać dodatkowe szczegóły pamięci z niektórych bardziej wymagających procesów. Życzę szczęścia!
Matt
źródło
Być może masz krótkotrwałe procesy, które zużywają dużo pamięci, a następnie wyjdź, zanim będziesz mieć szansę je zauważyć.
I tak byłoby to zgodne z tym, co widzisz.
źródło
Czy badałeś problemy z pamięcią podręczną i-węzłów?
slabtoppowinien przynajmniej dać ci punkt wyjścia, jeśli napotykasz coś takiego.źródło
Chociaż twój system jest 64-bitowy, system może nie być w stanie adresować całej dostępnej pamięci. Jest to ograniczenie mikroukładu. Na przykład Mac mini poprzedniej generacji „obsługuje” 4 GB pamięci RAM, ale tylko 3,3 GB faktycznie można było adresować.
źródło