Dotaz: Debian - nevyuziva pamet

[dobraczek]

Příloha:

• pamet.PNG (16922 bytů)

Netusite prosim nekdo, proc Debian (virtualizace VMware) vyuziva maximalne cca 3.5 GB pameti i kdyz mam aktualne prirazeno 64 GB? Jedna se o verzi HW wmware 14. Jde mi primarne o Apache2, ktery dost casto vraci odpoved 503. Spolu s debianem mam nainstalovan ISPConfig a zkousel jsem nastavovat vyssi limit (pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers...) nic z toho nevedlo k nicemu dobramu, ba naopak castejsi zobrazovani 503.

Zkousel jsem i navysovat pamet napr. "memory_limit = 51200M" a to take nepomohlo + nastavil jsem ve vmware "Reserve all guest memory (All locked)" a to take nic....

Dekuji za jakoukoliv radu, ktera povede k vyreseni meho problemu.

Verze debianu:

Distributor ID: Debian
Description:    Debian GNU/Linux 9.9 (stretch)
Release:        9.9
Codename:       stretch
(Linux ssd 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u2 (2019-05-13) x86_64)

Verze vmware:

VMware vSphere 6 Essentials

---

---

Odpovědi

[majales]

A co tam je za obsah? Ty 503 může způsobovat něco jiného než nedostatek prostředků. Je tam php jako modul nebo php-fpm? Zkoušel jsem nějaký load test? Asi by měli růst data v diskové cache, pokud je jich servírováno hodně. Nebo tahá něco z nějaké databáze z jiné virtuálky?

[j]

Hele a na co se vlastne ptas? Horkotezko dedukuju, ze ti jde o apache, nikoli o debian. System jako takovej nijak zvlast moc ramky nepotrebuje, a pokud mu das, tak se ji pokusi vuzit jako diskovou cache - samozrejme pokud to dava smysl = probihaji nejaky diskovy operace.

Mno a apache ... ten taky nijak zvlast moc ramky nepotrebuje, takze neni duvod proc by si ji bral Protoze podle toho prdu co pises se da usoudit, ze tam mas tak maximalne jednu html stranku.

Zato je z toho tvyho oprazku videt, ze ses slepej. Bezi si tam JEDEN thread, kterej dava CPU totalne naprdel, a tudiz nestiha.

---

Dete s tim guuglem dopice!

[Max]

Podle mně řešíš problém tam, kde žádný není. Jednak nejde o to, že by Debian nevyužíval paměť naplno, jde o to, že tu paměť si ty aplikace nealokují, protože asi víc nepotřebují (nebo nemají více povoleno).
Pokud máš problémy, že ti Apache vyhazuje 503, tak bude problém s tou aplikací, u které ti to dělá. Pokud je to něco v php, tak si musíš poladit nastavení php. Pokud má aplikace pomalé odezvy, tak musíš zjistit proč, zda je limit na databázi, nebo zda máš moc souborů v cache a vstup do takového adresáře generuje neúměrné zatížení disku, nebo zda php nemá moc nízký limit na paměť apod.
Zdar Max
PS: v tom obrázku je vidět, že ti něco zatěžuje jedno jádro na 100%, buď náhoda při focení, nebo něco nedobrého

[dobraczek]

Zatizeni jednoho jadra byla spise nahoda pri foceni. Zatizeni je rozlozene. Zkousel jsem ruzna nastaveni jak PHP, tak Apache2. Na databaze jsem jeste nekoukal. Tam by mohl byt problem. Stejna aplikace jede na jinych serverech a problem tam neni. Jen zde je vyssi navstevnost. Odpadne vzdy pouze jeden virtualhost. Ostatni jednou.

[Andrej]

Jaký přesně problém řešíš?

Zamrzá to a vidíš v dmesg OOM Killer?

Jestli ne, pak nechápu, kde je problém.

Popiš raději, co přesně nefunguje (stran výkonu nebo spolehlivosti), nikoliv pokusy o diagnostiku, které jdou leckdy od začátku špatným směrem.

[dobraczek]

Resil jsem hlavne chybu 503 pri vysoke navstevnosti a zdalo se mi hodne divne, ze pamet ani procesor nic nevykazoval. Odhaduji, ze jsem asi problem vyresil, poznam to, ale az se navstevnost opet navysi.

Hadam, ze mohl byt problem MariaDB/MySQL v defaultni hodnote "max_connections", ktera udava pocet soucasnych povolenych klientu a je v defaultu na 151. Coz je hodne malo pri rozsahlejsim aplikaci.

[Вherzet]

Ak je v tom, tak pripadne este povol HTTP2.

[Вherzet]

Pozrel si sa na apache error.log?

[ehmmm]

A ja mam naopak pocit, ze Debian tu volnou pamet (kterou nechce Apache) docela vyuziva a ze to je ten zluty pruh v htop. Neco podobneho ukazuje i "free -h".

Taky bych spis prozkoumal toho Apache + PHP + DB. U apache je dobry access.log+error.log. U MySQL ti neporadim, ale ke kazde normalni DB existuje nejaky nastroj pro sledovani, co dela a jak efektivne provadi dotazy.

A potom jeste primo v systemu je v "top" drobna vyhoda proti "htop", ze u polozky "wa" u jednoho zakaznika bylo videt, jak se ceka na uloziste. A v "iotop" bylo videt, kolik toho po tom ulozisti DB chce. Taky to bylo videt v grafech VMwaru.