Paweł Rohde pisze:

Paweł Rohde pisze:

...

Witam,

Przenoszę system ze slackware 10 na ubuntu server 8.04 LTS

Logowanie do nowego systemu trwa dłuuuuuugo (stary 3s nowy 22s)

Stary serwer to: 2xPIII 800MHz 512RAM mysql: 5.0.24a

Nowy serwer to: 2xPIII 1400MHz 2024RAM mysql: 5.0.51a-3ubuntu5.4

Ilość wykonywanych zapytań przy odświeżaniu strony info na starym: 166 Ilość wykonywanych zapytań przy odświeżaniu strony info na nowym: 1211337

Co on do cholery robi ?

Chyba winny jest customersview:

A dokładniej to zapytanie: SELECT SUM(value) FROM cash LEFT JOIN customersview ON customerid = customersview.id WHERE deleted = 0 GROUP BY customerid HAVING SUM(value) < 0;

wykonywanie odpowiednio: (11.49 sec) i (1.10 sec)

nie umiem czytać niestety explain dla mysql :(

mysql> explain extended SELECT SUM(value) FROM cash LEFT JOIN customersview ON customerid = customersview.id WHERE deleted = 0 GROUP BY customerid HAVING SUM(value) < 0; +----+--------------------+-------+--------+-----------------------------------------------------------------------+-----------------+---------+----------------------------------+-------+---------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+--------------------+-------+--------+-----------------------------------------------------------------------+-----------------+---------+----------------------------------+-------+---------------------------------+ | 1 | PRIMARY | cash | ALL | customerid | NULL | NULL | NULL | 49004 | Using temporary; Using filesort | | 1 | PRIMARY | c | eq_ref | PRIMARY,id_2,id | PRIMARY | 4 | lms2.cash.customerid | 1 | Using where | | 3 | DEPENDENT SUBQUERY | e | index | NULL | userid | 8 | NULL | 30 | Using where; Using index | | 3 | DEPENDENT SUBQUERY | a | eq_ref | customergroupid,customergroupid_2,customergroupid_3,customergroupid_4 | customergroupid | 8 | lms2.e.customergroupid,lms2.c.id | 1 | Using where; Using index | +----+--------------------+-------+--------+-----------------------------------------------------------------------+-----------------+---------+----------------------------------+-------+---------------------------------+ 4 rows in set, 2 warnings (0.01 sec)

!DSPAM:4aaeb6f3278461910919020!

A.L.E.C pisze:

Paweł Rohde wrote:

...

...

...

Nowy serwer to: 2xPIII 1400MHz 2024RAM mysql: 5.0.51a-3ubuntu5.4

...

SELECT SUM(value) FROM cash LEFT JOIN customersview ON customerid = customersview.id WHERE deleted = 0 GROUP BY customerid HAVING SUM(value) < 0;

wykonywanie odpowiednio: (11.49 sec) i (1.10 sec)

Udało mi się wyczytać w manualu, że przy takim joinie where jest brany pod uwagę tylko dla lewej tablicy. Czyli w tym przypadku jest wykonany skan cash (~50k rekordów) i potem z customersview. Co daje w wyniku ponad 1200000 odczytów.

Odwróciłem to zapytanie: SELECT SUM(value) FROM customersview LEFT JOIN cash ON customersview.id = customerid WHERE deleted = 0 GROUP BY customerid HAVING SUM(value) < 0;

I czas zrobił mi się porównywalny ze starym serwerem. Niemniej wczytywanie welcome na starym nadal jest szybsze (1.2s nowy 1.7s)

Nie jesteś pierwszym, który zgłasza problemy z wydajnością tej wersji mysqla.

Hmmmm.... poszukam, dzięki za to info. Paweł

!DSPAM:4aaf41e7303981804284693!

A.L.E.C pisze:

Paweł Rohde wrote:

...

Udało mi się wyczytać w manualu, że przy takim joinie where jest brany pod uwagę tylko dla lewej tablicy.

Nie chodzi mi resoultseta tylko o wyciąganie danych z tablicy.

A zobacz co zrobi jak usuniesz słówko LEFT, jest ono tutaj zbędne. Kolejność tabel też nie powinna tutaj mieć znaczenia. Jeśli baza nie potrafi tego optymalnie wykonać to jest to błąd bazy (jej konfiguracji?).

Konfigurację już nawet wziołem identiko ze starego serwera, jeszcze zastanawiam się czy jakieś aparmory i inne nowości w stosunku do slacka nie robią wiochy.

Chociaż wyciągnięte czyste zapytanie z trace'a i puszczone z mysql konsoli wykonywało się dłużej jak wyżej. Tak więc tak jak piszesz, chyba jest to kwestia wersji, jeszcze muszę sprawdzić phpinfo na obu serwerach, może znajdę coś ciekawego.

Być może problemem jest tutaj widok. Ktoś już zgłaszał podobny problem, ale ten ktoś miał InnoDB. Sprawdź co baza zrobi jak zamienisz customersview na customers.

Wystarczy że odwrócę kolejność i jest szybko. Zwykły join też działa dobrze.

O! jeszcze jedna sprawa. Założyłem index na deleted i teraz mi wybiera wszystko po indexie:

+----+--------------------+-------+--------+-----------------------------------------------------------------------+-----------------+---------+----------------------------------+------+----------------------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+--------------------+-------+--------+-----------------------------------------------------------------------+-----------------+---------+----------------------------------+------+----------------------------------------------+ | 1 | PRIMARY | c | ref | idx_deleted | idx_deleted | 1 | const | 653 | Using where; Using temporary; Using filesort | | 1 | PRIMARY | cash | ref | customerid | customerid | 4 | lms2.c.id | 46 | | | 3 | DEPENDENT SUBQUERY | e | index | NULL | userid | 8 | NULL | 30 | Using where; Using index | | 3 | DEPENDENT SUBQUERY | a | eq_ref | customergroupid,customergroupid_2,customergroupid_3,customergroupid_4 | customergroupid | 8 | lms2.e.customergroupid,lms2.c.id | 1 | Using where; Using index | +----+--------------------+-------+--------+-----------------------------------------------------------------------+-----------------+---------+----------------------------------+------+----------------------------------------------+

I w tym momencie ilość zapytań skróciła się do 3. (odczytuję ze status przed zapytaniem i po, dla przypomnienia bez indeksu było tego 1211337

Ot opisuję przygodę, może się komuś przyda....