Řešení 1:
Blahopřejeme k tomu, že máte populární webovou stránku a podařilo se vám ji po celou tu dobu udržet na virtuálním počítači.
Pokud skutečně zaznamenáváte dva miliony zobrazení stránek za den, nahromadíte v souborovém systému HODNĚ relací PHP a jejich odstranění bude trvat dlouho, bez ohledu na to, zda použijete fuser nebo rm nebo vysavač.
V tomto bodě bych vám doporučil podívat se na alternativní způsoby ukládání relací:
- Jednou možností je ukládat relace do
memcached. To je bleskurychlé, ale pokud se server zhroutí nebo restartuje, všechny vaše relace jsou ztraceny a všichni jsou odhlášeni. - Relace můžete také ukládat do databáze. Bylo by to o něco pomalejší než memcached, ale databáze by byla trvalá a staré relace byste mohli vymazat jednoduchým dotazem SQL. Chcete-li to však implementovat, musíte napsat vlastní obslužný program relace.
Řešení 2:
Odstranění fuser by měl pomoci. Tato úloha spustí fuser (zkontrolujte, zda je soubor aktuálně otevřen) pro každý nalezený soubor relace, což může na vytíženém systému se 14k relacemi snadno trvat několik minut. Toto byla chyba Debianu (Ubuntu je založeno na Debianu).
Místo memcached můžete také zkusit použít tmpfs (souborový systém v paměti) pro soubory relace. Podobně jako u memcached by to při restartu zneplatnilo relace (to lze obejít zálohováním tohoto adresáře někde ve skriptu vypnutí a obnovením ve spouštěcím skriptu), ale nastavení bude mnohem jednodušší. Ale to nepomůže s fuser problém.
Řešení 3:
Možnosti úložiště Memcached a úložiště databázových relací, které zde uživatelé navrhují, jsou tedy dobrou volbou pro zvýšení výkonu, přičemž každá má své výhody a nevýhody.
Ale testováním výkonu jsem zjistil, že obrovské náklady na výkon této údržby relace jsou téměř zcela způsobeny voláním fuser v práci cron. Zde jsou grafy výkonu po návratu k úloze Natty / Oneiric cron, která používá rm místo fuser pro oříznutí starých relací dojde k přepnutí ve 2:30.
Můžete vidět, že pravidelné snižování výkonu způsobené čištěním relace PHP Ubuntu je téměř úplně odstraněno. Špičky zobrazené v grafu Disk Operations jsou nyní mnohem menší a jsou zhruba tak hubené, jak může tento graf změřit, ukazující malé, krátké přerušení, kde byl dříve výkon serveru po dobu 25 minut výrazně snížen. Extra využití CPU je zcela eliminováno, toto je nyní úloha vázaná na IO.
(nesouvisející IO úloha běží v 05:00 a CPU úloha běží v 7:40, což obě způsobuje své vlastní skoky na těchto grafech)
Upravená úloha cron, kterou nyní spouštím, je:
09 * * * * root [ -x /usr/lib/php5/maxlifetime ] && \
[ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 \
-maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 \
| xargs -n 200 -r -0 rm