Dotaz: Apache+PHP+Oracle

[Scendel]

Dobrý den,

rád bych se zeptal, zda někdo tuto konfiguraci nepoužívá, mám problém, že při větším počtu uživatelů mi souměrně stoupá i počet připojení do Oracle

root@ora-web:/home/# netstat -tanpe|grep 1521 | grep ESTABLISHED |wc -l 80 root@ora-web:/home/# ps -aux|grep apache2 |wc -l 89

konfigurace apache:

 mpm_prefork_module>
    ServerLimit          20
    StartServers          2
    MaxClients          130
    MinSpareThreads      5
    MaxSpareThreads      15
    ThreadsPerChild      64
    MaxRequestWorkers   100
    MaxRequestsPerChild   0

v php je nastaveno přes OCI persistentní připojeni, potřebuji nějak omezit počet připojení do databáze, přeci není možné, když budu mít 1000 připojení na web server, aby bylo 1000 připojeni do Oracle, zkoušel jsem různě měnit nastaveni apache, ale už si opravdu nevím rady, jedná se Ubutnu LTS server 14

když by Vás něco napadlo, tak prosím poradtě

Děkuji Vám

Odpovědi

[Ivan]

PHP a Oracle je hodne spatna kombinace. Pamatuju si, ze kdysi nekdo na FEL CVUT napsal jako diplomku neco co fungovalo jako MaxConnect pro Informix. Tzn na web serveru bezi samostatny proceses, ktery drzi konexe do databaze, a samotne PHP worder procesy s nim mluvi pres IPC.

Jeste si vzominam, ze Oracle ma neco podobnyho a jmenuje se to DRCP.

[Scendel]

diky za reakci, DRCP je bohuzel az od Oracle 11 ja řeším Oracle 10, kde nic podobného není když bych dokázal upravit apache aby jeden worker mohl obslouzit vice klientu, protoze co proces apache, to connect do db .. mam mpm_prefork nevím jestli by se stejně choval mpm_worker ...

[OldFrog {Ondra Nemecek}]

PS: DRCP je normální connection pooling, což se liší od persistentního spojení. Rozdíl je popsaný např. http://www.databasesoup.com/2013/07/connection-pooling-vs-persistent.html Connection pooling je úplně běžně používaná technika a nijak nesouvisí s tím, zda je Oracle vhodná pro použití ve spojení PHP.

[OldFrog {Ondra Nemecek}]

MaxClients máte na 130, takže víc než 130 požadavků se nebude současně obsluhovat a tedy by nemělo být ani víc připojení do databáze. Funguje to tak? Pokud ne, je někde problém a chtělo by ho to najít, protože tvrdé nastavení limitu na počet konexí do databáze by nic neřešilo - sice by se snížil počet připojení do databáze, ale aplikace by neměla dostat spojení a házela by chybu.

Tvrdé nastavení limitu na počet persistentních spojení lze udělat pomocí oci8.max_persistent. Jelikož jedno persistentní připojení může využívat jen jeden běžící php skript, měla by být hodnota max_persistent nastavena na hodnotu MaxClients, tedy 130 (+ nějaká rezerva).

Pokud se hromadí připojení do databáze je někde problém. Mají všechna databázová spojení stejné přihlašovací údaje? Podaří se persistentní spojení skutečně vytvořit? Pokud se nepodaří persistentní připojení, uzavře se pak normální nepersistentní připojení? To lze otestovat na jednoduchém testovacím skriptu a pak ladit teprve v aplikaci.

[Ivan]

Tezko rict co je horsi, jestli velke mnozstvi necinnych konexi, anebo to, ze se spojeni budou otevirat pri kazdym kliknuti na strance. V pripade Oracle ma vytvoreni DB spojeni dost velky overhaed.

[Scendel]

MaxClient na 130 funguje, to je ale špatně, já nemůžu omezovat klienty, oci8.max_persistent mám nastaveno na 1 to znamená když bych nasatvil na 130 tak by přes jeden php proces mohlo být 130 spojení které by se tvářilo v oracle jako jedno připojeni ? ted to je tuším tak, že každý proces apache vytvoří připojeni do db, což je špatně

do db se přihlašuje přes jeden účet v celé aplikaci, spojení se nehromadí, při novém požadavku se v oracle v pořádku vytvoří a si korektně zavřou

Děkuji Vám za pomoc.

[OldFrog {Ondra Nemecek}]

Hmm, máte pravdu http://php.net/manual/en/oci8.configuration.php#ini.oci8.max-persistent je maximální počet připojení pro jeden PHP proces, tedy 1 je správně.

Abyste jedním spojením do databáze obsloužil více http požadavků, to bez connection poolingu nebo aplikační mezivrstvy asi neuděláte.

Celé to nicméně vede k tomu se zamyslit, kolik těch http požadavků vlastně chcete obsloužit - nějaký limit tam stejně bude muset být (limitem zajistíte, že ten systém nepůjde při přetížení do kytek pro vyčerpání ram a překročení dalších limitů operačního systému). Podle plánovaného vytížení je pak potřeba systém navrhnout. Výkon systému nelze přeci garantovat donekonečna.

Pokud skutečně potřebujete mít 1000 klientů v jeden okamžik tak k tomu musí být navrhnuta odpovídající infrastruktura. Přijde mi to hrozně mnoho - v reálu se provede požadavek za řekněme 100ms-200ms a jakmile skončí, může být spojení znova použito. Takže těch 1000 konexí by odpovídalo 5000-10000 požadavkům za sekundu, což je dost frmol. Váš limit 130 by odpovídal 650-1300 za sekundu. Doporučuju prostě změřit, kolik požadavků to vládne při jakém limitu a jak se to chová. Pro měření lze použít třeba ab nebo pro složitější případy jmeter.

[Scendel]

Děkuji za reakci,

asi to nějak nechápu, nebo mám někde špatně nastavený limity, zrovna ted mam takovýto stav:

root@ora-web3:/home/petr# netstat -tanpe|grep 1521 | grep ESTABLISHED |wc -l 100

root@ora-web3:/home/petr# ps -aux|grep apache2 |wc -l 106

to znamená 100 spojení do db a 106 přes apache, je v tom tedy přibližně stejná úměra, tedy 500 spojeni na apache a 500 spojení do db, což už je pro Oracle hodně, je tam plno dalších spojení z jiných aplikaci

přijde mi, že to spojení z php se drží déle, než jak píšete v tom příkladu, v php.ini mám oci8.persistent_timeout = 60

v apachi mám ohledně timeoutu toto:

Timeout 300
KeepAlive On
MaxKeepAliveRequests 300
KeepAliveTimeout 30

a modul prefork mám nastavený takto:


StartServers              3
MinSpareServers           5
MaxSpareServers          10
MaxRequestWorkers        190
MaxConnectionsPerChild   0

takže jestli tomu dobře rozumím, tak mám možnost jen 190 současných připojení, myslel jsem, že když se pustí 3 servery, že se to bude násobit, tedy 3*190

takže to vypadá, že nejsem schopný nastavit apache, aby těch spojení do db dělal méně.

Děkuji za pomoc

[OldFrog {Ondra Nemecek}]

Jenže ono tam prostě to jedno spojení do databáze pro každý běžící php skript (v případě varianty bez persistentního spojení) případně pro každý připravený php proces apache (v případě varianty s persistentním spojením) být musí. Použitá technologie nic jiného neumožňuje.

Zároveň obecně u každé aplikace platí, že je nutno počet spojení omezit, jinak tomu dojde dech a upadne to. Proto i vy budete muset klienty omezit, tomu se jednoduše nejde vyhnout.

Takže jde jen o to, na kolik to omezit a kde. A to pak záleží na tom, kolik dalších aplikací tam běží, zda se také připojují do databáze apod. Pokud na serveru běží jen jedna aplikace (= nejjednodužší varianta), pak prostě nastavte MaxClients. Na jakou hodnotu musíte uvážit sám - je to rozhodnutí technické (kolik server a databáze unese) a obchodní (kolika uživatelům jsem to slíbil).

Jinými slovy: Přestaňte na chvíli koukat do konfiguráku a výpisu procesů a zamyslete se! Nad tím, pro koho ta aplikace je, co má dělat, co se stane, když nepoběží, kdy je špička ve využití, proč to vlastně řešíte. Podívejte se do statistik využití v průběhu dne a týdne. Až budete vědět, jak byste to chtěl nastavit (bez ohledu na to, zda to umíte), proberte to se zodpovědným nadřízeným a pak klidně zde.

[OldFrog {Ondra Nemecek}]

PS: A můj předchozí výpočet pro 1000 spojení do databáze z tohoto čísla pouze odvodil počet http requestů do aplikace za sekundu (za předpokladu, že bude skript běžet 100-200ms). To jsem počítal proto, abyste měl představu, že 1000 spojení do databáze by představovalo ohromný http provoz. A tedy že ani limit 130 http klientů dost možná reálné uživatele nijak neomezí.

[OldFrog {Ondra Nemecek}]

PPS: Apache si drží určitý počet procesů nebo vláken (podle použitého workeru) připravených k akci - i když momentálně neprobíhá žádný http požadavek. A v rámci těchto procesů příp. vláken se drží i ta spojení do databáze - tedy pokud jsou persistentní. To je právě princip té perzistence.

Různé limity na počet procesů, které se vytvoří rovnou po startu apache, na maximální počet procesů atd. pak už jen ovlivňuje, jak se s těmi předpřipravenými procesy nakládá. To je předmětem té konfigurace.

[OldFrog {Ondra Nemecek}]

A poslední PS: Konfigurace preforku stručně ručně a česky v několika větách například zde http://www.dasm.cz/clanek/apache-a-jeho-multi-processing-moduly#konfigurace-modelu Takže u preforku skutečně nastavit MaxClients na hodnotu, kolik maximálně chcete spojení do databáze. Pokud je tam víc aplikací, které v apache běží, je to problém, protože a musí se to omezení řešit trochu jinak. Třeba pomocí proxy nebo nějakého modulu, z hlavy teď nevím.

[Scendel]

Děkuji Vám za odpovědi,

moc mi to pomohlo, byl jsem totiž obviněn z toho, že apache server je špatně nakonfigurovám a přetěžuje oracle databazi, která pak kolabuje, ale jak jsem pochopil, tak není technicky možné v mém případě počet spojení do db omezit, řešení je DRCP, ale to by znamelo migraci na Oracle 11, nebo zvýšit limit současných db serveru.

Petr

[OldFrog {Ondra Nemecek}]

Jako řešení můžete nabídnout omezení na počet klientů (MaxClients), které se ovšem uplatní v rámci celého Apache. Za nastavení limitů do databáze a nekolabování databáze ručí správce databáze, nikoli správce http serveru. Vy zodpovídáte, že nekolabuje http server.

Vaší správnou reakcí je vyvolat debatu o tom, kolik uživatelů má ta aplikace obsloužit a pak to tak nastavit. Tím může hodnocení vaší kompetence akorát stoupnout DRCP by situaci sice řešit mohl, ale to záleží na důvodech, proč Oracle padá a dalších podrobnostech.

Jinak jsem rád pomohl. Hodně zdaru.

[Ivan]

Dulezite je vedet pod jakym uzivatelem se aplikace hlasi do databaze. Jestli je to genericky aplikacni user anebo ma kazdy uzivatel svoje jmeno/heslo v DB. Pokud mate 190 Workeru a 10 uzivatelu (v DB) tak muzete skoncit az s 1900 otevrenymi konexemi.

Z pohledu databaze je problem, ze limit na pocet konexi se neda zvysit bez restartu. Vyzira to zbytecne pamet na strane DB serveru. Dalsi uzivatele se nemohou prihlasit do DB z jinych aplikaci, protoze nejsou volne konexe. A navic nejsis nefunguje ani monitoring, protoze ani ten se nemuze prihlasit.

Architektura PHP aplikaci v tomhle pripade dost zoufala. Persistentni spojeni do db, bud skutecne drzi TCP konexi do DB, anebo si PHP zapise login a haslo do nejakeho soubory v /tmp a kdyz tu session promennou pouzijete, tak to spojeni napozadi samo vytvori.

Pokud jde o ten timeout, ten se muze uplatnit jen v pripade ze ten worker process nekdo "probudi" spravnym zpusobem. Kdyz worker pracuje, tak nejak jak ten timout zkontrolovat. Neverim, ze by to bylo udelane vice-vlaknove, a ze by nejaky thread tohle kontroloval na pozadi.

Dalsi moznosti jak to omezit je snizit MaxRequestPerChild. Pokud worker umre po (skoro) kazdem kliknuti, tak zadne zbytecne db konexe drzet nebude.

[Scendel]

aplikace se hlásí do db pod jedním účtem, když budu reagovat na předchozí příspěvek, tak Oracle právě kolabuje, že mu dochází počet volných připojení, ty jsou vázaný na operační paměť, když dojdou, tak se aplikace nedá používat, dlouhé odezvy, timeouty, apod. přitom web servery o které se starám jsou skoro nevytížené ...

zkusím to sepsat jak jste mi všichni radili, mám aspoň nějaké argumenty, pro svojí obhajobu ...:)

Petr

[Arnošt Málek]

Já jsem persistentní spojení úpně vypnul a nepoužívám jej. Měl jsem s ním problémy. Dopad na výkonost jsme nezaznamenal.