Dotaz: Subjektivně pomalé PHP + MySQL

[Milan Uhrák]

Zdravím tučňáky

Mám dotaz ohledně rychlosti PHP. Jsem jen programátor amatér, a kamarádovi jsem napsal .. aplikaci (?) na skladovou evidenci .. Nyní jsem řešil archivaci dat ( odsunout data aktuálního období ( doklady + položky ) do archivních tabulek. Dokladů je +- 350, položek skoro 2000.

Skript zahrnuje načtení všech dokladů zvoleného období (roku) do paměti, a po určitých kontrolách dat zobrazí potvrzení pro pokračování v archivaci.

Těch 350 dokladů ale archivuje 75 sekund při nulovém zatížení serveru ( mysql 5% http 1% jinak nikde nic ). skript pro samotnou archivaci jede "na jeden zátah", žádné ajaxoviny nebo tak. Jelikož má aplikace vestavěný vlastní logování, v logu vidím, že jeden doklad řeší přibližně 0,3s, to zahrnuje: * uložení dat dokladu (načteného v paměti), získání nového ID * načtení položek dokladu ( prům. tak 5-6 položek ), přepsání ID tím novým (v paměti - v poli ), jejich uložení do archivní tabulky, a smazání v aktuální tabulce. * smazání dokladu v aktuální tabulce

položky jsou ukládány a mazány najednou, t.j. jedním sql-kem.

Skript funguje, t.j. data jsou převedena do archivu správně, ale je to pomalé.

Mám několik nápadů, jak vysledovat, kde se to zadírá, (logovat časy funkcí nebo tak ) ale zase server se fláká, zatížení žádné.

Nemáte nějaké nápady, jak zjistit, kde to vázne ?

V PHPMyAdminu nemám u sebe žádné omezení co se počtu queries per hour týče

Předem díky..

Milan

---

---

Odpovědi

[Jendа]

ale zase server se fláká, zatížení žádné

A sledoval jsi i, jestli mysql nevisí na I/O? (v "D" stavu)

Pokud se každý ten dotaz samostatně commituje, tak by to na pomalém rotačním disku mohlo trvat…

[Milan Uhrák]

Ahoj,

díky za naťuknutí, ale nevím, jestli se commituje .. sázím dotazy rovnou přes mysqli->query(). Rotační disk tam je, ale jsou 3 ( raid 5 ) relativně nové, 2TB.

Jak zjistím, že je v D stavu ?

[Bedňa]

Rotační disk tam je, ale jsou 3 ( raid 5 )

Což znamená, že se změna musí zapsat na všechny, takže to bude trvat dýl…

díky za naťuknutí, ale nevím, jestli se commituje .. sázím dotazy rovnou přes mysqli->query()

Tak to se commituje. Nevím jestli jsou dotazy na sobě závislé, ale zkusil bych START TRANSACTION, pak vypsat všechny ty inserty a pak COMMIT.

[Milan Uhrák]

Jeníku,

zdá se žes to trefil ... trochu jsem musel postudovat, jak to s těmi transakcemi je ( vlastně díky za toto ) a obnova databáze ze zálohy z 45s na 10s ...

archivace (a vše vypadá v pohodě ) 0.6s .... uff

Moc díky za nasměrování,

M

[Milan Uhrák]

Tak mě napadlo, že to bude status v top-u...

A fakt .. takže v D stavu se v době vykonávání archivace objevuje jdb2/dm-0-8 ... i když jen mžikově ... chvíli jo, pak zase ne ..

Nápad ? Já jsem tady v koncích.

[Kit]

Vyzkoušel bych to na jiném stroji.

[Milan Uhrák]

Tak ne, je v D skoro pořád, oprava po lepším "sledování"

[Milan Uhrák]

oddíl s databázi je připojen

/dev/mapper/data_lvm-data on /data type ext4 (rw,relatime,user_xattr,acl,barrier=1,data=ordered)

[Kit]

Určitě to vázne v mizerně napsaném skriptu.

[.]

Zkus to nějak extrahovat do minimální podoby, kterou můžeš sdílet. Spousta lidí tady ti pak dokáže konkrétně říct, co by šlo udělat lépe.

[OldFrog {Ondra Nemecek}]

Zdá se, že to je již vyřešeno, stačilo to zabalit do transakce.