wydajnosc mysql
=?ISO-8859-2?Q?Mateusz_=A6l=EAzak?= - 03-02-2006 09:52
wydajnosc mysql
Witajcie.
Mam następujący problem.
Mam dużą baze z dużym obciążeniem (jak dla mnie) w mysql.
(
Uptime: 14100 Threads: 35 Questions: 1298487 Slow queries: 22 Opens:
212 Flush tables: 1 Open tables: 155 Queries per second avg: 92.091
)
Stała sobie ona na dedykowanym serwerze p4 1.8 1gb ram zwykły składak z
debianem 3.0.
Postanowiłem więc w mojej nieskończonej mądrości zakupić w nowy
bezpieczniejszy serwer z raidem itp specjalnie pod tą baze będąc święcie
przekonany że dopałka będzie niewyobrażalna.
zakupiliśmy ibm x225 3x36gb w raidzie 5, 1x xeon 2.6 1gbram.
Postawiłem sobie na nim ubuntu-server a na nim mysql z paczki.
Ponieważ nie ja odpalałem ani nie ja konfigurowałem poprzedni serwer -
przeniosłem wszystkie ustawienia mysql dokładnie tak jak były na poprzednim.
Okazało się ze po uruchomieniu tego produkcyjnie chodzi to ciut wolniej
a do tego ma "zacięcia" pare razy na godzine które bardzo dużym echem
odbijają sie na moim telefonie. (kilkunasto sekundowe opóźnienia zapytań)
więc zaczołem grzebać
zobaczyłem, (memstat) że pół ramu zjada mi libresolv
/lib/tls/i686/cmov/libresolv.....
więc wrzuciłem do confa mysql - skip-name-resolve
co pomogło na libresolv.
Teraz natomiast pół ramu zjada mi
443508k: PID 7817 (/lib/tls/i686/cmov/libnss_files-2.3.5.so)
domyślam się ze to ma jakis punkt wspólny z ustawieniem key-buffer w
confie mysql, ale nie jestem przekonany czy to jest poprawne.
Podpowiedzcie mi coś jak mogę poprawić wydajność bazy, ewentualnie gdzie
mam szukac przyczyn takiego stanu.
Pewnie zapomniałem czegoś napisać, ale może daje to jakis ogólny obraz
problemu.
i pare danych:
Linux ibm 2.6.12-9-386 #1 Mon Oct 10 13:14:36 BST 2005 i686 GNU/Linux
mysql Ver 12.22 Distrib 4.0.24, for pc-linux-gnu (i486)
top - 15:18:30 up 21:59, 1 user, load average: 0.08, 0.07, 0.12
Tasks: 46 total, 2 running, 44 sleeping, 0 stopped, 0 zombie
Cpu(s): 7.3% us, 14.3% sy, 0.0% ni, 0.0% id, 77.7% wa, 0.0% hi, 0.7%si
Mem: 1036624k total, 1023416k used, 13208k free, 4k buffers
Swap: 976112k total, 12476k used, 963636k free, 910764k cached
my.cnf:
skip-innodb
skip-bdb
skip-name-resolve
skip-host-cache
long_query_time=10
key_buffer=400M
max_allowed_packet=8M
table_cache=512
sort_buffer=5M
sort_buffer_size=5M
read_buffer_size=5M
record_buffer=5M
thread_cache=16
max_connections=2000
max_tmp_tables=500
back_log=100
server-id=200
query-cache-size = 20M
query-cache-type = 1
kilka z nich testowo zmieniam co pare dni
ale ogolnie wygląda podobnie
Dzieki z góry za ewentualne podpowiedzi
Mateusz Ślęzak
Radosław Witkowicki - 03-02-2006 09:52
Witajcie.
Mam następujący problem.
Mam dużą baze z dużym obciążeniem (jak dla mnie) w mysql.
(
Uptime: 14100 Threads: 35 Questions: 1298487 Slow queries: 22 Opens:
212 Flush tables: 1 Open tables: 155 Queries per second avg: 92.091
)
Stała sobie ona na dedykowanym serwerze p4 1.8 1gb ram zwykły składak z
debianem 3.0.
Postanowiłem więc w mojej nieskończonej mądrości zakupić w nowy
bezpieczniejszy serwer z raidem itp specjalnie pod tą baze będąc święcie
przekonany że dopałka będzie niewyobrażalna.
zakupiliśmy ibm x225 3x36gb w raidzie 5, 1x xeon 2.6 1gbram.
Postawiłem sobie na nim ubuntu-server a na nim mysql z paczki.
Ponieważ nie ja odpalałem ani nie ja konfigurowałem poprzedni serwer -
przeniosłem wszystkie ustawienia mysql dokładnie tak jak były na poprzednim.
Okazało się ze po uruchomieniu tego produkcyjnie chodzi to ciut wolniej
a do tego ma "zacięcia" pare razy na godzine które bardzo dużym echem
odbijają sie na moim telefonie. (kilkunasto sekundowe opóźnienia zapytań)
więc zaczołem grzebać
zobaczyłem, (memstat) że pół ramu zjada mi libresolv
/lib/tls/i686/cmov/libresolv.....
więc wrzuciłem do confa mysql - skip-name-resolve
co pomogło na libresolv.
Teraz natomiast pół ramu zjada mi
443508k: PID 7817 (/lib/tls/i686/cmov/libnss_files-2.3.5.so)
domyślam się ze to ma jakis punkt wspólny z ustawieniem key-buffer w
confie mysql, ale nie jestem przekonany czy to jest poprawne.
Podpowiedzcie mi coś jak mogę poprawić wydajność bazy, ewentualnie gdzie
mam szukac przyczyn takiego stanu.
Pewnie zapomniałem czegoś napisać, ale może daje to jakis ogólny obraz
problemu.
i pare danych:
Linux ibm 2.6.12-9-386 #1 Mon Oct 10 13:14:36 BST 2005 i686 GNU/Linux
mysql Ver 12.22 Distrib 4.0.24, for pc-linux-gnu (i486)
top - 15:18:30 up 21:59, 1 user, load average: 0.08, 0.07, 0.12
Tasks: 46 total, 2 running, 44 sleeping, 0 stopped, 0 zombie
Cpu(s): 7.3% us, 14.3% sy, 0.0% ni, 0.0% id, 77.7% wa, 0.0% hi, 0.7% si
Mem: 1036624k total, 1023416k used, 13208k free, 4k buffers
Swap: 976112k total, 12476k used, 963636k free, 910764k cached
my.cnf:
skip-innodb
skip-bdb
skip-name-resolve
skip-host-cache
long_query_time=10
key_buffer=400M
max_allowed_packet=8M
table_cache=512
sort_buffer=5M
sort_buffer_size=5M
read_buffer_size=5M
record_buffer=5M
thread_cache=16
max_connections=2000
max_tmp_tables=500
back_log=100
server-id=200
query-cache-size = 20M
query-cache-type = 1
kilka z nich testowo zmieniam co pare dni
ale ogolnie wygląda podobnie
1. Nie RAID, bo to działa jak krew z nosa. Lepszym rązwiązaniem będzie SCSI.
2. Jakby nie było MySQL jak każda inna baza danych łyknie każdą ilość
pamięci RAM, więc RAM-u można dołożyć.
Pozdro
Maciek Zobniow - 03-02-2006 09:52
Mateusz Ślęzak wrote:
> Witajcie.
>
> Mam następujący problem.
> Mam dużą baze z dużym obciążeniem (jak dla mnie) w mysql.
> (
> Uptime: 14100 Threads: 35 Questions: 1298487 Slow queries: 22 Opens:
> 212 Flush tables: 1 Open tables: 155 Queries per second avg: 92.091
> )
>
> Stała sobie ona na dedykowanym serwerze p4 1.8 1gb ram zwykły składak z
> debianem 3.0.
> Postanowiłem więc w mojej nieskończonej mądrości zakupić w nowy
> bezpieczniejszy serwer z raidem itp specjalnie pod tą baze będąc święcie
> przekonany że dopałka będzie niewyobrażalna.
>
> zakupiliśmy ibm x225 3x36gb w raidzie 5, 1x xeon 2.6 1gbram.
Powinienes glownie zainwestowac w wieksza pamiec - im wiecej tym lepiej.
Procek wymienilbym raczej na amd64, najlepiej dual. Jesli masz duzo
zapisow to raid5 moze troche opozniac.
> Postawiłem sobie na nim ubuntu-server a na nim mysql z paczki.
>
> Ponieważ nie ja odpalałem ani nie ja konfigurowałem poprzedni serwer -
> przeniosłem wszystkie ustawienia mysql dokładnie tak jak były na
> poprzednim.
> Okazało się ze po uruchomieniu tego produkcyjnie chodzi to ciut wolniej
> a do tego ma "zacięcia" pare razy na godzine które bardzo dużym echem
> odbijają sie na moim telefonie. (kilkunasto sekundowe opóźnienia zapytań)
Rozumiem ze chodzi ci o duze zapytania ktore blokuja insetry i updaty, a
te blokuja selecty?
Korzystajac z listowania procesow, postaraj sie wylapac te query ktore
przycinaja baze i je jakos zoptymalizowac.
> więc zaczołem grzebać
> zobaczyłem, (memstat) że pół ramu zjada mi libresolv
> /lib/tls/i686/cmov/libresolv.....
> więc wrzuciłem do confa mysql - skip-name-resolve
> co pomogło na libresolv.
> Teraz natomiast pół ramu zjada mi
> 443508k: PID 7817 (/lib/tls/i686/cmov/libnss_files-2.3.5.so)
> domyślam się ze to ma jakis punkt wspólny z ustawieniem key-buffer w
> confie mysql, ale nie jestem przekonany czy to jest poprawne.
>
> Podpowiedzcie mi coś jak mogę poprawić wydajność bazy, ewentualnie gdzie
> mam szukac przyczyn takiego stanu.
>
> Pewnie zapomniałem czegoś napisać, ale może daje to jakis ogólny obraz
> problemu.
>
> i pare danych:
> Linux ibm 2.6.12-9-386 #1 Mon Oct 10 13:14:36 BST 2005 i686 GNU/Linux
> mysql Ver 12.22 Distrib 4.0.24, for pc-linux-gnu (i486)
>
> top - 15:18:30 up 21:59, 1 user, load average: 0.08, 0.07, 0.12
> Tasks: 46 total, 2 running, 44 sleeping, 0 stopped, 0 zombie
> Cpu(s): 7.3% us, 14.3% sy, 0.0% ni, 0.0% id, 77.7% wa, 0.0% hi,
> 0.7% si
> Mem: 1036624k total, 1023416k used, 13208k free, 4k buffers
> Swap: 976112k total, 12476k used, 963636k free, 910764k cached
>
> my.cnf:
>
> skip-innodb
> skip-bdb
> skip-name-resolve
> skip-host-cache
> long_query_time=10
> key_buffer=400M
Przesada - masz za malo pamieci. Mysql bazuje na systemowym I/O cache w
linuxie przy czytaniu danych z tabel, powinienes wiec zostawic jakies
75% pamieci dla systemu.
> max_allowed_packet=8M
> table_cache=512
> sort_buffer=5M
> sort_buffer_size=5M
> read_buffer_size=5M
> record_buffer=5M
> thread_cache=16
> max_connections=2000
To moze doproweadzic do tego ze pewnego pieknego dnia odwiedzi cie oom
killer.
Pzdr
Maciek
=?ISO-8859-2?Q?Mateusz_=A6l=EAzak?= - 03-02-2006 09:52
Rados napisał(a):
> 1. Nie RAID, bo to działa jak krew z nosa. Lepszym rązwiązaniem będzie SCSI.
Raid na scsi. Na kontrolerze IBM Serveraid 5i sprzętowy raid5 na 3
dyskach 10k rpm 36gb
> 2. Jakby nie było MySQL jak każda inna baza danych łyknie każdąilość
> pamięci RAM, więc RAM-u można dołożyć.
tak zrobie.
> Pozdro
wzajemnie.
Radosław Witkowicki - 03-02-2006 09:52
Procek wymienilbym raczej na amd64, najlepiej dual.
>>> Najlepiej na Opterona, ale lepiej sobie radzą procki, ale na serwerach
>>> lepiej sobie radzą procki Intela Xeon-y.
Maciek Zobniow - 03-02-2006 09:53
Radosław Witkowicki wrote:
> Procek wymienilbym raczej na amd64, najlepiej dual.
>
>
>>>>Najlepiej na Opterona, ale lepiej sobie radzą procki, ale na serwerach
>>>>lepiej sobie radzą procki Intela Xeon-y.
>
Mam kilka serverow dual Xeonow i amd64. Prawda jest taka ze te xeony
wymiekaja przy nawet o polowe nizej taktowanych opteronach. Szczegolnie
pod baza mysql.
Pzdr
Maciek
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
[mysql] =?ISO-8859-2?Q?Za=E6mienie=2E=2E=2E_jak_wy=B6wietli=E6?==?ISO-8859-2?Q?=2E=2E=2E?=
[mysql] =?ISO-8859-2?Q?wielko=B6=E6_bazy_a_stabilno=B6=E6=2C?==?ISO-8859-2?Q?_podzia=B3_du=BFej_bazy_a_powi=B1zania_tabel?=
[MySQL] =?ISO-8859-2?Q?Wy=B6wietlenie_kolejnej_pozycji=2C_?==?ISO-8859-2?Q?jak=B1_mia=B3by_dany_rekord=2C_gdybym_czyta=B3 _?==?ISO-8859-2?Q?wg_konkretnych_kryteri=F3w=2E_Da_si=EA_=3F?=
[mysql 4.0.x] przenoszenie kolum =?ISO-8859-2?Q?mi=EAdzy_bazam?==?ISO-8859-2?Q?i_cd_=2E=2E=2E_?=
[MySQL] =?ISO-8859-2?Q?z=B3=B1czenie_tabeli_u=BFytkownik_i?==?ISO-8859-2?Q?_zdj=EAcia_z_wyborem_zdj=EAcia_domy=B6lnego?=
[MySQL] Jak =?ISO-8859-2?Q?wpisa=E6_do_tabeli_pozycje_dl?==?ISO-8859-2?Q?a_wierszy_gdybym_te_wiersze_wybiera=B3_w_ok?== ?ISO-8859-2?Q?re=B6lonej_kolejno=B6ci_=3F?=
Gdzie MySQL 4.1, a gdzie 5.0?
[MySQL 4.0...4.1] zabezpieczenie przed =?ISO-8859-2?Q?jednoczesn?==?ISO-8859-2?Q?=B1_edycj=B1?=
[MS SQL] "set names" (mySQL) w MS SQL
[mysql 5.x] jak =?ISO-8859-2?Q?zrealizowa=E6_zapytanie=3F_cz?==?ISO-8859-2?Q?yli_podzapytanie_i_wi=EAcej_ni=BF_jeden_rz=B1? ==?ISO-8859-2?Q?d_wynik=F3w?=
zanotowane.pldoc.pisz.plpdf.pisz.pllatwa-kasiora.pev.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
