Upgrade 4.7-re

HUP

Hamarosan upgrade 4.7-re. Kisebb kiesések várhatók a frissítés idejére!

Köszönjük a türelmet!

  • 3526 megtekintés

( trey | 2006. 05. 12., p – 19:50 )

Egyelőre vissza a régire. Elég csúnya dolgokat művelt. Kell ezen még csiszolnom.

--
trey @ gépház

A frissítés tökéletesen lement. Az oldal is működik 4.7-en. Legalább 20 teszt upgrade-t csináltam. Ez valamiért összeszakadt. Lesz second try. Valószínűleg nem ezen a gépen csinálom meg az adatbázis upgrade-et, mert ez kib. lassú (egy HUP dump betöltés "menet közben" van hogy 70 perc), kevés benne a RAM, és folyamatos terhelés alatt van. A mirror-on jobb lesz, csak annak az internet sávját jelenleg "szerelik".

--
trey @ gépház

Jah, ezekre van megoldás. Egyelőre arra nincs, hogy FreeBSD-n miért tart egy hozzászólás postolása 10-60 sec-ig (a mirror-on is, ami jóval bikább gép mint ez), amíg a "szar" 2.6-os Linux desktopomon 1.7 load, futó X, stb. mellett tizedmásodpercekben mérhető....

--
trey @ gépház

Nos megvan a válasz a lassú postolásra a Drupal 4.7-en. Bekapcsoltam a MySQL-ben log-slow-queries-t és azt látom, hogy postázásnál lefut egy ilyen query:

# User@Host: root[root] @ localhost []
# Query_time: 5 Lock_time: 0 Rows_sent: 15 Rows_examined: 412106
SELECT c.nid, c.subject, c.cid, c.timestamp FROM comments c INNER JOIN node n ON n.nid = c.nid WHERE n.status = 1 AND c.status = 0 ORDER BY c.timestamp DESC LIMIT 0, 15;

SELECT c.nid, c.subject, c.cid, c.timestamp FROM comments c INNER JOIN node n ON n.nid = c.nid WHERE n.status = 1 AND c.status = 0 ORDER BY c.timestamp DESC LIMIT 0, 15;

Ez frissíti a "Friss hozzászólások" blokkot. Ha kikapcsolom a nevezett blokkot, akkor a postázás olyan, mint a ~villám. FreeBSD-n is, de Linux-on még mindig gyorsabb. OK. Vajon miért?

Hogy miért van ez (első futtatás mindegyik gépen, ugyanaz az adatbázis), valaki megmagyarázhatná. A FreeBSD-ken optimalizálva a MySQL, a lehető legrészletesebben konfigurálva. A Linux-on binárisból (apt-get install mysql-server, azt jóvan') feltéve, alig konfigurálva (éppen csak elinduljon):

HUP:

FreeBSD 6.1-PRERELEASE, Intel dual P3, 1 GB RAM (kb. 0.4-es load mellett)

mysql> SELECT c.nid, c.subject, c.cid, c.timestamp FROM comments c INNER JOIN node n ON n.nid = c.nid WHERE n.status = 1 AND c.status = 0 ORDER BY c.timestamp DESC LIMIT 0, 15;

[...]

+-------+------------------------------+--------+------------+
15 rows in set (24.55 sec)

Mirror:

FreeBSD 6.1-RELEASE, AMD Opteron, 1 GB RAM szerver (no X, majdnem 0 load mellett):

mysql> SELECT c.nid, c.subject, c.cid, c.timestamp FROM comments c INNER JOIN node n ON n.nid = c.nid WHERE n.status = 1 AND c.status = 0 ORDER BY c.timestamp DESC LIMIT 0, 15;

[...]

+-------+-----------------------------+--------+------------+
15 rows in set (6.41 sec)

Alderaan (én notebookom):

Ubuntu Linux, Intel P4, 768 MB RAM (notebook, full X, kb. 1.00-es load mellett)

mysql> SELECT c.nid, c.subject, c.cid, c.timestamp FROM comments c INNER JOIN node n ON n.nid = c.nid WHERE n.status = 1 AND c.status = 0 ORDER BY c.timestamp DESC LIMIT 0, 15;

[...]

+-------+------------------------------+--------+------------+
15 rows in set (0.09 sec)

Azt tudtam már eddig is, hogy FreeBSD nem egy MySQL bajnok, de ha ez így van, akkor - és ez nem vicc - az új gépre nem FreeBSD, hanem Linux fog kerülni.

--
trey @ gépház

Ugyanazon a gépen sysbench eredmények, innodb táblával, read write módban, növekvő párhuzamossággal (konkurrens threadek száma):
FreeBSD:
1 204.62
2 330.12
4 532.95
8 786.10
16 849.33
32 830.82
64 788.46
128 675.70
256 471.29
512 484.19
1024 167.30

Linux:
1 198.67
2 203.20
4 200.94
8 199.76
16 199.92
32 201.24
64 200.90
...

Igazából ezt nem is ide, hanem a "miért nincs naplózó fájlrendszer FreeBSD-re" newbie-sírás topicba kellene írnom. Hát ezért.
Ja a fenti egyértelműen IO korlátos, egy SATA diszkről ment...

Mysql konfig azonos? Milyen fájlrendszer van a linuxon? Milyen utasításokat hajt végre az a postolás? A táblatípusok megegyeznek? indexek ugyanazok? Táblaméret, tartalom azonos? Fordítási opciók megegyeznek (statikus, dinamikus, azonos gcc, 32/64 bit)? FreeBSD-n milyen threading library, milyen kernel? timecounter beállítás?

Így első körben ezeket nézném meg. Például a drupal halála a myisam tábla.

Most ez csináltam. A jelenlegi HUP adatbázist kidumpoltam. Majd be drupaltest néven. Megupgradeltem. Amikor kész lett (első futtatás):

mysql> use drupaltest;
Database changed
mysql> SELECT c.nid, c.subject, c.cid, c.timestamp FROM comments c INNER JOIN node n ON n.nid = c.nid WHERE n.status = 1 AND c.status = 0 ORDER BY c.timestamp DESC LIMIT 0, 15;
+-------+------------------------------+--------+------------+
| nid | subject | cid | timestamp |
+-------+------------------------------+--------+------------+
| 25010 | Látszik, hogy új van a | 202001 | 1147526515 |
| 25024 | Tehát már írtál a | 202000 | 1147526414 |
| 25017 | ugy tünik, | 201999 | 1147525693 |
| 25010 | Jaja, ezeken az elmúlt pár | 201998 | 1147525692 |
| 25010 | Akkor valóban nem, ha a | 201997 | 1147525413 |
| 25027 | Akkor már csak a bementei | 201996 | 1147525400 |
| 25017 | Jaj, jaj... Ha ez a CD a | 201995 | 1147524878 |
| 25010 | 24.55/0.09
272.77
Ekkora | 201994 | 1147524781 |
| 24992 | szerintem le:)
bar a | 201993 | 1147524776 |
| 25002 | az szamit, hogy egy bizonyos | 201992 | 1147524571 |
| 25010 | Hali!
Persze lehet | 201991 | 1147524570 |
| 24992 | ezt nem ertem:)
mi a vicc | 201990 | 1147524412 |
| 25010 | Mysql konfig azonos? Milyen | 201989 | 1147524046 |
| 24728 | Hello..
Az interju keszitoje | 201988 | 1147523962 |
| 25027 | Csak egy kis | 201987 | 1147523844 |
+-------+------------------------------+--------+------------+
15 rows in set (44.38 sec)

Ugyanezt, ugyanezzel az adatbázissal most megcsinálom Linuxon. Ezt fogom letölteni... (jövök az eredménnyel).

--
trey @ gépház

Lehet, hogy itt van elásva a kutya. Ez a query nem igazán optimális és átmeneti táblát csinál, amely ha diszken jön létre (és nem heap tábla formájában), eléggé agyoncsaphatja a teljesítményt, ami már amúgy is szar (using filesort, using temporary).
A reiserfs-eden lehet, hogy diszk io nélkül létrejön, majd megszűnik az ideiglenes tábla, míg az ufs-en történik némi fizikai írás...

Igen, egy ilyen select lefuttatása közben (a vége felé) kb. 40MBps io van... Itt meg ugye még duplán is kell kiírni (RAID1).

Ahogy elnézem eléggé köthető a futtatásához. Így hirtelen két dolog rémlik, ami diszk alapú temp táblát csinál, az a mező hosszúsága (heapben mintha 256 karakteres lehetne csak) és a temp táblákhoz köthető különféle memóriabeállítások.

Igazából ezt a selectet kellene úgy megírni, hogy eltűnjön az explainből a filesort és a temporary.

Ó, most látom, hogy erről már értekeztünk.
Nos, a hup-on egy ilyen temporary sort tábla létrehozása a jobb oldali friss hozzászólások doboz megjelenítéséért akár 3-400 MB diszkre írását is jelentheti.

Ez nem kevés. Végigolvasva a fenti threadet egyetlen dolgot tudok elképzelni: a linuxod ezt a 3-400 MB-ot nem írja ki a diszkre, csak behazudja a MySQL-nek és a cache-ben dirtyként szerepel, majd szinte azonnal törli a MySQL, így végül nem kerül kiírásra soha.

Érdemes lenne megnézni ezt a problémát adatvesztési oldalról. :)

Igen. Mivel a MySQL első indítás után mértem. Indexek meg mindenhol ugyanott kell, hogy legyenek, mert ugyanazt a adatbázist upgrade-ltem. Semmi különbség nincs szerintem.

De végülis ha nem mérem, akkor is látszik, hogy a Linuxon egy postázás akkor is gyorsabb, ha be van kapcsolva a blokk (lefut a query), mint FreeBSD-n, amikor nincs bekapcsolva (nem fut le).

--
trey @ gépház

Biztos? A drupaltest adatbazison? Most már futtattam elég sokat. Elsőre 25 sec volt.

Ezt most futtattam mysql restart után:

mysql> use drupaltest; Database changed
mysql> SELECT c.nid, c.subject, c.cid, c.timestamp FROM comments c INNER JOIN node n ON n.nid = c.nid WHERE n.status = 1 AND c.status = 0 ORDER BY c.timestamp DESC LIMIT 0, 15;

+-------+------------------------------+--------+------------+
15 rows in set (26.50 sec)

--
trey @ gépház

Ugyanez Linuxon:

root@alderaan:/home/trey# /etc/init.d/mysql stop
Stopping MySQL database server: mysqld.
root@alderaan:/home/trey# /etc/init.d/mysql start
Starting MySQL database server: mysqld.
Checking for crashed MySQL tables in the background.
root@alderaan:/home/trey# mysql
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 5 to server version: 4.1.15-Debian_1ubuntu5-log

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> use drupaltest;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> SELECT c.nid, c.subject, c.cid, c.timestamp FROM comments c INNER JOIN node n ON n.nid = c.nid WHERE n.status = 1 AND c.status = 0 ORDER BY c.timestamp DESC LIMIT 0, 15;
+-------+------------------------------+--------+------------+
| nid | subject | cid | timestamp |
+-------+------------------------------+--------+------------+
| 24771 | --
trey @ gépház
| 199663 | 1147471629 |
| 24491 | --
trey @ gépház
| 199662 | 1147471607 |
| 24785 | --
trey @ gépház
| 199661 | 1147471577 |
| 24785 | --
trey @ gépház
| 199660 | 1147471560 |
| 24785 | realtime-ban akarod az | 199659 | 1146869193 |
| 24785 | Nem nagy valami volta | 199658 | 1146868642 |
| 24777 | hat nemtom de amiota az | 199657 | 1146868606 |
| 24735 | megneztem, barmilyen font-al | 199656 | 1146868058 |
| 24785 | helo !
en az effektet anno | 199655 | 1146867980 |
| 24755 | csak kicsik rajta az | 199654 | 1146867822 |
| 24785 | Én is gitározok, és anno, | 199653 | 1146866941 |
| 24755 | Pontosan ilyen géppel | 199652 | 1146866043 |
| 24735 | jól néz ki, megszoktam, | 199651 | 1146866017 |
| 24640 | A fene sem gondolta hogy | 199650 | 1146865458 |
| 24782 | Kicsit off, de hogy lehet | 199649 | 1146863189 |
+-------+------------------------------+--------+------------+
15 rows in set (0.00 sec)

--
trey @ gépház

"mert full table scant csinált a marha több százezer sorra..."

Az egy dolog, hogy szarul van implementálva. Most arról van szó, hogy ez a szar implementáció Linuxon nagyságrendekkel gyorsabb. Egyébként tuti, hogy a fejlesztők sem hülyék és 20-30 sec-es post time-okkal nem adnak ki valamit. Ők tuti Linuxra fejlesztenek.

--
trey @ gépház

Akkor valóban nem, ha a threading lib. hibátlan.
Ebben az esetben nem erről van szó.
A guglin jópár találat van ebben a témában. Csak lehet benne vmi.

"The problem of MySQL threads not "noticing" that they were killed turned out to be bug in the FreeBSD kernel. That bug has been patched in FreeBSD 5.0."

"The solution, as mentioned earlier, is to compile MySQL with the -DHAVE_BROKEN_REALPATH option. MySQL's configure script has been updated to do that automatically on FreeBSD systems. And a new implementation of realpath() was recently committed to FreeBSD's CVS repository."

Illetve még1 oldal:
http://www.bsdforums.org/forums/showthread.php?threadid=10182

Itt elég jó vélemények vannak a cikkről. Nem olvastam el rendesen magát a cikket, tehát nemtom hogy ezt a belassulásos problémát orvosolja-e, de szvsz megér egy próbát.

kl223

Joh könnyedén megeshet.
De a köv. szövegből indultam ki a fentebb írt linken:
"...turned out to be bug in the..."

Mert ugye csak lehet hiba benne... :P és miután a szerző a linuxthreads libet javasolja lecserélésre.....

Na amúgy teljesen mind1. Nem ezen kéne vitatkozni ebben a topikban. Azért írtam be mert eddig nem írta senki ezt a linket. Gondoltam elkerülte a figyelmeteket.
Nem értem miért kell ezután mentegetőznöm.

Kíváncsi leszek mi lesz végül a megoldás.

kl223

Mielőtt ilyeneket írsz, kérlek nézz már utána annak, hogy mikori az a FreeBSD 5.0-ás, hogy mi is az, amiben ez a bug volt (gyk: egy teljesen új megoldás a 4-eshez képest) és hogy mi most a divat (mysql-hez libthr).

Tudom, a szándék a fontos, de ha már google-zol, akkor csináld jól. :)

( LiRul v | 2006. 05. 13., szo – 19:22 )

Ezek szerint a mostani gep is linux-2.6-tal rohogve kiszolgalna' a latogatokat? :-)

Learn (My)SQL, vághatnék vissza. :)

Egyébként ha megnézed a drupal.org-ot, ott is megy állandóan a sírás, hogy milyen tetű az egész. Látszik, hogy csak írogatnak bele a nagyvilágba, de az optimalizációra, meg MySQL doksi olvasásra senkinek sem jut ideje. Ezzel a "Linuxra optimalizált" szöveggel meg el lehet menni, tudod hová ezek ismeretében. :)

( trey | 2006. 05. 14., v – 18:08 )

Na a lassú postolást megworkaroundoltam (de szép szó). A megoldás, postolásnál nem fut le a query mert nem jelenik meg a "Friss hozzászólások" blokk. Erre lehetőséget az a Drupal (hogy bizonyos blokkok csak bizonyos oldalakon jelenjenek meg). Egyébként logikus is, mi a francnak kéne látni, amikor valaki választ ír egy cikkre vagy hozzászólásra?

Teszt time:

http://hup.hu/ujhup

--
trey @ gépház

Jah, pedig az a blokk okozza a gondot. Most teljesen kikapcsoltam, mint a szélvész. Ha bekapcsolom, akkor széjjelszakad.

Got error 12 from storage engine query: SELECT c.nid, c.subject, c.cid, c.timestamp FROM comments c INNER JOIN node n ON n.nid = c.nid WHERE n.status = 1 AND c.status = 0 ORDER BY c.timestamp DESC LIMIT 0, 15 - /data/www/ujhup/includes/database.mysql.inc - 120. sor.

Ilyenet sem szégyell dobálni.

Na ezen még reszelni kell.

--
trey @ gépház

Jo lenne valahogyan merni, hogy hanyan kattintanak a friss hozzaszolasok ablakban levo linkekre. Mindezt azert mondom, mert szerintem el kellene felejteni az egesz blokkot upgrade/gepcsere utan is. Useless. Nem az alapjan a harom szo alapjan fogok kattintani. (Persze magambol valo kiindulas esete forog fent.)

( ghost | 2006. 05. 16., k – 09:43 )

Nem olvastam végig a hozzászólásokat, de valami nem stimmel a user beléptetéssel, a főoldalon be vagyok lépve, de a creativos cikkhez nem tudok hozzászólni, mert visszadob hogy nem vagyok belépbe. Jelszó jó. Ide meg tudok írni

No megygyógyult, de hogy ez mitől volt. :)
--
A bus station is where a bus stops. A train station is where a train stops. On my desk, I have a work station