Problemy z serwerem MySQL...

[MX^Lucas 0]

Witam serdecznie...

 

Posiadam kilka serwerow i na jednym wlasnie natrafilem na problemy z polaczeniem bazy, gdzie wyskakiwal blad typu: Too Many connections, czyli krotko mowiac, limit polaczen zostala przekroczona.

 

A dokladniej jest tak, wszystko chodzi pieknie ladnie, a jezeli liczba rzeczywistych procesow, ktore trwaja dluzej niz 10 sekund wzrosnie do 50 (sprawdzam za pomoca ps -A | grep mysqld | wc), wtedy wszystkie polaczenie nie tylko sa zapychane tworzac blad typu Too many conections, a takze obciaza mocno serwer httpd.

 

Zwiekszylem limit w pliku my.cnf max-connections, ale to nie zdaje egzaminu. Czy moglbym poprosic o pomoc co moge w tej sprawie zrobic, jakie sa rozwiazania, zeby tego typu blad sie nie pojawial, jak zoptymalizowac serwer MySQL pod duza liczbe polaczen oraz obciazenia.

 

Opieram sie na dystrybucji Fedora Core, MySQL 3.23.58 i znalazlem domyslne ustawienia:

 

back_log              current value: 50

bdb_cache_size        current value: 8388600

bdb_log_buffer_size   current value: 0

bdb_max_lock          current value: 10000

bdb_lock_max          current value: 10000

binlog_cache_size     current value: 32768

connect_timeout       current value: 20

delayed_insert_timeout  current value: 300

delayed_insert_limit  current value: 100

delayed_queue_size    current value: 1000

flush_time            current value: 0

innodb_mirrored_log_groups  current value: 1

innodb_log_files_in_group  current value: 2

innodb_log_file_size  current value: 5242880

innodb_log_buffer_size  current value: 1048576

innodb_buffer_pool_size  current value: 8388608

innodb_additional_mem_pool_size  current value: 1048576

innodb_file_io_threads  current value: 4

innodb_lock_wait_timeout  current value: 50

innodb_thread_concurrency  current value: 8

innodb_force_recovery  current value: 0

interactive_timeout   current value: 20

join_buffer_size      current value: 33550336 

key_buffer_size       current value: 104853504

long_query_time       current value: 10

lower_case_table_names  current value: 0

max_allowed_packet    current value: 16776192

max_binlog_cache_size  current value: 4294967295

max_binlog_size       current value: 1073741824

max_connections       current value: 1000

max_connect_errors    current value: 10

max_delayed_threads   current value: 40

max_heap_table_size   current value: 16777216

max_join_size         current value: 4294967295

max_sort_length       current value: 1024

max_tmp_tables        current value: 32

max_user_connections  current value: 10

max_write_lock_count  current value: 4294967295

myisam_max_extra_sort_file_size  current value: 256

myisam_max_sort_file_size  current value: 2047

myisam_sort_buffer_size  current value: 8388608

net_buffer_length     current value: 16384

net_retry_count       current value: 10

net_read_timeout      current value: 30

net_write_timeout     current value: 60

open_files_limit      current value: 0

query_buffer_size     current value: 0

record_buffer         current value: 131072

record_rnd_buffer     current value: 0

slave_net_timeout     current value: 3600

slow_launch_time      current value: 2

sort_buffer           current value: 2097144

table_cache           current value: 1024

thread_concurrency    current value: 10

thread_cache_size     current value: 0

tmp_table_size        current value: 33554432

thread_stack          current value: 65536

wait_timeout          current value: 20

 

Bede wdzieczny za szybka pomoc i rozwiazanie tego problemu.

 

Pozdrawiam

Łukasz

[Gość adamszendzielorz]

max_user_connections  current value: 10

[MX^Lucas 0]

Witam ponownie...

 

Ale to nic nie pomaga, zmniejszylem liczbe nawet do 5 i nic z tego.

 

Na biezaco serwer obsluguje szybko zapytania do bazy MYSQL, ale jak liczba procesor mysqld zwiekszy sie do 40, gdzie procesy zamiast wykonywac w ulamku sekundy operacje, po prostu zacinaja sie, spowalniaja i co gorsza, sa tworzone gwaltowanie procesy w ciagu sekudny, dwie moze przybyc nagle setka, dwiescie procesow oczekujacych serwera MySQL.

 

Dlatego moze sa jakies jeszcze rozwiazania?...

 

Pozdrawiam serdecznie

Łukasz

[Gość adamszendzielorz]

Ale to nic nie pomaga, zmniejszylem liczbe nawet do 5 i nic z tego.

 

Do 5 ? A czy te zmiany na pewno sa widoczne w samym MySQLu? Zmieniasz to we wlasciwym konfigu ? Rebootujesz oczywiscie za kazda zmiana MySQLa?

 

I dalej jest komunikat "too many connections" ?

 

Na biezaco serwer obsluguje szybko zapytania do bazy MYSQL, ale jak liczba procesor mysqld zwiekszy sie do 40, gdzie procesy zamiast wykonywac w ulamku sekundy operacje, po prostu zacinaja sie, spowalniaja i co gorsza, sa tworzone gwaltowanie procesy w ciagu sekudny, dwie moze przybyc nagle setka, dwiescie procesow oczekujacych serwera MySQL.

 

Jaka maszyna - jaki CPU, jakie dyski i ile RAMu ?

Ile masz wykorzystanego swapa w czasie takiej "akcji" ?

pozdr.

[tomasz.b 0]

Hi!

 

Do tego problemu podszedlbym troche inaczej. W pierwszej kolejnosci nalezy odpowiedziec dlaczego dochodzi do tak wysokiej liczby procesow. Czestym powodem jest brak pamieci, systemowi brakuje pamieci i uzywa pamieci "swap", kazdy nowy proces mysql spowalnia system, ktory w koncu moze zawiesic sie. Dobrym rozwiazaniem jest zdeaktywowanie polaczenia stalego do mysql. Czyli w php.ini "mysql.allow_persistent = Off".

 

Przedmowca mial na mysli, ze masz powiekszyc "max_user_connections current value: 10"

 

Gruss

tomasz

[MX^Lucas 0]

Witam ponownie...

 

Do 5 ? A czy te zmiany na pewno sa widoczne w samym MySQLu? Zmieniasz to we wlasciwym konfigu ? Rebootujesz oczywiscie za kazda zmiana MySQLa?

Wlasnie zmniejszylem do 5 polaczen i narazie pierwszy raz chwilowo serwer MySQL wyrabia sie z polaczeniami, ale sytuacja jest troszke niestabilna. Nie rebootuje calego serwera, tylko uruchamiam od nowa usluge, czego serwer MySQL potwierdza domyslne ustawienia takie jakie wprowadzilem do pliku my.cnf.

 

I dalej jest komunikat "too many connections" ?

 

Narazie nie, ale jezeli przy opcji'ps -A | grep mysqld | wc' zwiekszy sie do 40, wtedy z sekudny na sekunde rosnie kilkadziesiat procesow oczekujacych i wiadomo, taki komunikat zawita, a ja chce zmniejszyc ryzyko, zebym nie musial na przyszlosc co 15 minut restartowac caly serwer Apache wraz z MySQL.

 

Jaka maszyna - jaki CPU, jakie dyski i ile RAMu ?

Ile masz wykorzystanego swapa w czasie takiej "akcji" ?

pozdr.

 

Na tej maszynie to Fedora Core 2, z CPU Intel 2.6 Ghz, 1 GB ramu, 160 GB dysk. Uzycie swapa siega na poziomie 21%, czyli dokladnie 107 MB teraz.

 

Zaznaczam, ze ruch do serwera jest bardzo duzy, jezeli chodzi o liczbe odwiedzin.

 

Pozdrawiam serdecznie

Łukasz

[patryk 451]

Uzycie swapa siega na poziomie 21%, czyli dokladnie 107 MB teraz

 

Przy jakim uptime maszyny?

[Gość adamszendzielorz]

Wlasnie zmniejszylem do 5 polaczen i narazie pierwszy raz chwilowo serwer MySQL wyrabia sie z polaczeniami' date=' [/quote']

 

To Ci nic nie da. Bardziej maszyne obciaza Ci pewnie i tak co innego. Chyba ze masz jakiegos usera, ktory dobija MySQLa (obserwuj co tam sie dzieje przez "show full processlist" w konsoli). Zwieksz max_connections, max_user_connections i zajmij sie szukaniem przyczyny m.in. dosyc sporego wykorzystania swapa.

 

Na tej maszynie to Fedora Core 2' date=' z CPU Intel 2.6 Ghz, 1 GB ramu, 160 GB dysk. Uzycie swapa siega na poziomie 21%, czyli dokladnie 107 MB teraz.

[/quote']

 

Jeden dysk jak rozumiem? IDE (jeszcze tak duzy) w polaczeniu ze swapem na tym samym dysku to zabojstwo dla serwera. Tu masz przyczyne calego problemu. Wrzuc tam drugi dysk, przerzuc swapa na niego, przerzuc tez katalog "var" z mysqla, zlinkuj do nowej lokalizacji. Bardzo pomoze.. Ale to takie gdybanie - wiecej bedzie mozna powiedziec jak wkleisz troche vmstat 1.

 

Zaznaczam' date=' ze ruch do serwera jest bardzo duzy, jezeli chodzi o liczbe odwiedzin.[/quote']

 

W jakim trybie dziala PHP, czy apache byl wogole "tuningowany" czy to jakas standardowa wersja ?

 

Mocno pomoze Ci tez wlaczenie cache'owania w MySQL, zainteresuj sie:

 

query_cache_size

query_cache_type

query_cache_limit

 

Z doswiadczenia moge Ci powiedziec ze to moze zdzialac cuda

pozdr.

[MX^Lucas 0]

Witam ponownie...

 

Hi!

 

Do tego problemu podszedlbym troche inaczej. W pierwszej kolejnosci nalezy odpowiedziec dlaczego dochodzi do tak wysokiej liczby procesow. Czestym powodem jest brak pamieci, systemowi brakuje pamieci i uzywa pamieci "swap", kazdy nowy proces mysql spowalnia system, ktory w koncu moze zawiesic sie. Dobrym rozwiazaniem jest zdeaktywowanie polaczenia stalego do mysql. Czyli w php.ini "mysql.allow_persistent = Off".

 

Przedmowca mial na mysli, ze masz powiekszyc "max_user_connections current value: 10"

 

Gruss

tomasz

 

Podejrzewam, ze powodem byly wywolane bledne skrypty, albo petla, wiec proces mysql czeka na zakonczenie zadania, a skoro ma czas do 20 sekund (timeout), to i tak przez ten czas przybedzie kilkadziesiat podobnych procesow, no i mamy problem.

 

Co do powiekszenia, to mialem na samym poczatku ustawiona na wartosc 0, czyli bez limitu, ale coraz czesciej serwer MySQL padal, to dodalem wartosc 10, ale w tym przypadku pogorszylo sprawe i musialem restartowac serwer httpd, zeby skillowal wszystkie zamrozone procesy mysql. A jak przestawilem na 5, to pzrez pol godziny narazie dobrze sie sprawuje, ale mam obawy na przyszlosc.

 

Co do braku pamieci, swapa, to takiej sytuacji nie ma.

 

Przy jakim uptime maszyny?

 

Po restarcie serwera, przy uptime 12 godzin i 28 minut taka jest rzeczywistosc swapu, ktora sie zmienia w zaleznosci od dlugosc trwania... Serwer dzialal przez kilka miesiecy bez restartowania, a tu nagle juz od kilku dni natrafilem na powazne problemy z serwerem MySQL i czasem pierwszy raz bylem zmuszony restartowac serwer...

 

Pozdrawiam serdecznie

Łukasz

[patryk 451]

Po restarcie serwera, przy uptime 12 godzin i 28 minut taka jest rzeczywistosc swapu, ktora sie zmienia w zaleznosci od dlugosc trwania... Serwer dzialal przez kilka miesiecy bez restartowania, a tu nagle juz od kilku dni natrafilem na powazne problemy z serwerem MySQL i czasem pierwszy raz bylem zmuszony restartowac serwer...

 

Czyli jasno widać, ze maszyna nie wyrabia i korzysta nadmiernie ze swapu co daje takie mało fajne efekty. Generalnie polecam to co Adam - optymalizacja - cache dla SQLa, cache dla PHP, a przy okazji może update mysqla chociaż do serii 4.0.x, bo po drodze zapewne polepszyli wydajność i poprawili trochę błędów.

 

Jeśli i to nie da satysfakcjonujących efektów to zawsze można po prostu dodać trochę RAMu.. .

[Gość adamszendzielorz]

Podejrzewam, ze powodem byly wywolane bledne skrypty, albo petla, wiec proces mysql czeka na zakonczenie zadania, a skoro ma czas do 20 sekund (timeout), to i tak przez ten czas przybedzie kilkadziesiat podobnych procesow, no i mamy problem.

 

W tym momencie "show full processlist" i wszystko bedziesz wiedzial.

Bo byc moze "zamula" Ci dysk i mysql czeka na dostep do plikow z bazami (wtedy ma bodaj status "opening database" czy cos podobnego). W tym momencie dochodza nowe procesy (ktore rowniez pozeraja RAM), swap sie powieksza, tamte procesy caly czas czekaja, dochodza nowe, i tak w kolko az zabraknie ramu, swapa i serwer zdechnie

 

Po restarcie serwera, przy uptime 12 godzin i 28 minut

 

Przedmowcy chodzilo pewnie o load average (LA) ?

pozdr.

[patryk 451]

Przedmowcy chodzilo pewnie o load average (LA) ?

 

Chodziło mi przede wszystkim o uptime, bo że load ma w cholere wysoki przy jednym dysku i takim zapełnieniu swapa to się już domyślam . Miałem podobnie na jednej "produkcyjnej" maszynie. 200 MB swapu zajęte na dobry początek, MySQL wykazał zużywanie 600% zadeklarowanej pamięci :-).

[MX^Lucas 0]

Witam ponownie...

 

Load average, czy nawet srednie wykorzystanie CPU waha sie w przedziale 3.04, 2.82, 1.25... czyli krotko mowiac na biezaco monitoruje CPU, wiec nie jest wykorzystywany nawet wiecej niz 20%, inaczej mowiac, jezeli nagle pojawia sie ponad kilkaset procesow mysqld, wiec CPU gwaltowanie nadrabia zaleglosci...

 

Co do dysku, to owszem, wszystko jest na jednym dysku, na oddzielnych partycjach systemowe, a reszta /home, mysql jest wlasnie na drugim.

 

Jezeli chodzi o zajetosc, to po 3 miesiaca uptime zawsze wahalo sie zuzycie swapa srednio 200, 350 MB, nigdy wiecej, ani nigdy sie nie zdarzylo uzyc swap na 100%. A wiec w tej chwili RAM, CPU i wykorzystanie HDD nie maja narazie nic do rzeczy, gdyz wczesniej sprawdzalem, wiec zadna rzecz nie obciaza system.

 

Mocno pomoze Ci tez wlaczenie cache'owania w MySQL, zainteresuj sie:

 

query_cache_size

query_cache_type

query_cache_limit

Tak, to jest mysl, bo w tej chwili nie mam wlaczonego i w nablizszym czasie sprobuje dopisac do pliku my.cnf, wtedy zobaczy sie jak serwer MySQL bedzie sobie radzil. To pierwsza dobra propozycja za to dziekuje :-)

 

W jakim trybie dziala PHP, czy apache byl wogole "tuningowany" czy to jakas standardowa wersja ?

 

Tzn, w jakim trybie? Jezeli chodzi o serwer Apache, to standardowa wersja 2.x.x i nie bylo wogole tuningowany, jezeli chodzi o obciazenie, liczbe odwiedzin, zapytan itp.

 

Zwieksz max_connections, max_user_connections

Max_connection jest ustawione na 1000, wczesniej bylo na 100, gdy nie starczylo, zwiekszylem do 500, az podskoczylem do 1000, tylko blad 'To many connections' prawdopodobnie pochodzi z innej przyczyny, ze serwer pomimo wolnego polaczenia, to traktuje tenblad, tak jakby byl timeout, czyli brak odpowiedzi, jest taki blad.... I obawiam sie zwiekszenie tego limitu, bo jak sie okaze, ze na dzien dobry serwer zatnie sie z 1000 zamrozonych procesow? To nie bardzo bede wstanie zrestartowac komenda shutdown -r now...

 

Max_user_connections, to nie moze byc wieksza, poniewaz wystarczy, ze jeden uzytkownik bedzie generowal wadliwy skrypt, chociazby PHP z petla, to zamiast jednego procesu okaze sie, ze jeden uzytkownik zapcha caly serwer MySQL. A przy wartosci to pierwszy raz chyba dobrze chodzi, bez zarzutow i podobno jest mozliwosc zwiekszenia tego limitu za pomoca pliku .htaccess? Jezeli tak, to jak brzmi wpis??

 

hyba ze masz jakiegos usera, ktory dobija MySQLa (obserwuj co tam sie dzieje przez "show full processlist" w konsoli).

 

Tak, wlasnie, mam pare userow, ktorzy nagle pojawiaja sie w liscie procesow, co gorsza, czekaja na swoja kolejke i zapychaja... Na szczescie, ze jest tylko kilka, ale nim to zauwaze, to i tak nie znalazlem czasu sprawdzic, ktory to dokladnie. Co do polecenia show ful itp. to niestety, na fedorze cos takiego nie dziala...

 

tamte procesy caly czas czekaja, dochodza nowe, i tak w kolko az zabraknie ramu, swapa i serwer zdechnie

Wlasnie u mnie sytuacja jest troszke odwrotna, nie ma wykorzystania na 100% RAMu, ani swapa, jezeli zostaje zapchane polaczenie z serwerem MySQL, ale CPU szaleje...

 

Dobrym rozwiazaniem jest zdeaktywowanie polaczenia stalego do mysql. Czyli w php.ini "mysql.allow_persistent = Off".

 

Wlasnie tak wczoraj zrobilem, gdyz wczesniej to bylo przyczyna i pochodzilo kilkadziesiat godzin, nagly wzrost liczby odwiedzin i szlag trafilo z pieknym komunikatem... To many connections... A przy ps -A mysqld widze kilkaset :-|

 

Pozdrawiam serdecznie

Łukasz

[patryk 451]

Load average, czy nawet srednie wykorzystanie CPU waha sie w przedziale 3.04, 2.82, 1.25... czyli krotko mowiac na biezaco monitoruje CPU, wiec nie jest wykorzystywany nawet wiecej niz 20%, inaczej mowiac, jezeli nagle pojawia sie ponad kilkaset procesow mysqld, wiec CPU gwaltowanie nadrabia zaleglosci...

 

Load dla jednoprocesorowej maszyny nie powinnien być przez większość czasu jej działania (wyłączając tak lubiany "backup time" albo "generowanie statystyk mode") większy niż 1,00. Kazdy wyzszy oznacza, ze w danym momencie maszyna ma wiecej zadan do wykonania niz jest w stanie obsluzyc. Celeron zdechnie Ci przy loadzie 5-6 tak, że się do niego nie dopchasz. Coś bardziej wydajnego wytrzyma troszkę większy load zanim zwolni widocznie dla usera.

 

Przy dobrze skonfigurowanej maszynie z odp. dopasowanym kernelem, ulimits itd, itp swap nie powinnien byc zajety i uzywany praktycznie w ogole.

[Gość adamszendzielorz]

Jezeli chodzi o zajetosc, to po 3 miesiaca uptime zawsze wahalo sie zuzycie swapa srednio 200, 350 MB, nigdy wiecej, ani nigdy sie nie zdarzylo uzyc swap na 100%. A wiec w tej chwili RAM, CPU i wykorzystanie HDD nie maja narazie nic do rzeczy, gdyz wczesniej sprawdzalem, wiec zadna rzecz nie obciaza system.

 

Uzycie nawet paru MB swapa, jezeli ten swap jest na dysku IDE na ktorym sa pozostale rzeczy (system, dane) jest juz bardzo sporym obciazeniem. Uzycie 200-350MB swapa to kompletne nieporozumienie - to i tylko to jest podstawowym zrodlem Twoich problemow! Wiec albo dolozysz RAMu albo mocno zoptymalizujesz system (w szczegolnosci apache'a, konfiguracje php).

 

Tak, to jest mysl, bo w tej chwili nie mam wlaczonego i w nablizszym czasie sprobuje dopisac do pliku my.cnf, wtedy zobaczy sie jak serwer MySQL bedzie sobie radzil. To pierwsza dobra propozycja za to dziekuje :-)

 

Niestety musze ja cofnac - z takim uzyciem swapa nie masz wogole wolnego RAMu. Wlaczenie keszowania pogrubi mocno MySQLa (gdzies przeciez te keszowane dane musi trzymac:) a to skolei spowoduje jeszcze wieksze uzycie swapa i kolejny mocny spadek wydajnosci.

 

Generalnie przy jednym dysku IDE traktuj swapa jako cos zapasowego, cos co nigdy nie powinno byc wykorzystane w wiekszej liczbie niz max pare MB (czesc rzeczy rzadko w pamieci odswiezanych i tak zostanie przeniesiona do swapa wiec zawsze te pare MB bedzie uzyte).

 

Max_user_connections, to nie moze byc wieksza, poniewaz wystarczy, ze jeden uzytkownik bedzie generowal wadliwy skrypt, chociazby PHP z petla, to zamiast jednego procesu okaze sie, ze jeden uzytkownik zapcha caly serwer MySQL.

 

Masz racje - max_user_connections daj oczywiscie mniejsze od max_connections ale nie przesadzaj - 50 to IMO minimum.

 

A przy wartosci to pierwszy raz chyba dobrze chodzi, bez zarzutow i podobno jest mozliwosc zwiekszenia tego limitu za pomoca pliku .htaccess? Jezeli tak, to jak brzmi wpis??

 

W .htaccess mozesz jedynie sterowac ustawieniami PHP pod warunkiem, ze PHP dziala w trybie modulu do apache'a. Ustawien MySQLa tam nie zmienisz.

 

Co do polecenia show ful itp. to niestety, na fedorze cos takiego nie dziala...

 

Wykonujesz to w konsoli mysqla, logujesz sie do niej poleceniem (w shellu):

 

mysql -u root -p

(lub pelna sciezka - standardowo /usr/local/mysql/bin/mysql)

 

Wlasnie u mnie sytuacja jest troszke odwrotna, nie ma wykorzystania na 100% RAMu, ani swapa, jezeli zostaje zapchane polaczenie z serwerem MySQL, ale CPU szaleje...

 

Jezeli masz uzycie swapa na poziomie wiekszym niz kilkanascie MB to znaczy ze brakuje Ci RAMu. Wklej tutaj co wypluje Ci "vmstat 1" (potrzymaj przez kilkanascie sekund). Odpal tez "top", daj sortowanie wedlug pamieci ("M") i wklej zrzut calego ekranu (lacznie z gora).

pozdr.

[MX^Lucas 0]

Witam ponownie...

 

Jest prawie wszystko w porzadku, bylem zmuszony zwiekszyc limit max_user_connections do 9 poniewaz wystapowal czasami blad o przekroczeniu liczby uzytkownikow... I narazie procesy troszke niebzepiecznie sie zachowuja, ale dziala...

 

W .htaccess mozesz jedynie sterowac ustawieniami PHP pod warunkiem, ze PHP dziala w trybie modulu do apache'a. Ustawien MySQLa tam nie zmienisz.

Niezupelnie, mozna wyslac polecenie w sprawie ilosci polaczen, miejsca pliku mysql.socket, gdzie rowniez na ten temat mozna znalezc w opcji phpinfo(); w dziale mysql..

 

Kiedys za posrednictwem GOOGLE znalazlem pewien wpis do htaccess, gdzie mozna zwiekszyc limit polaczen w opcji max_user_connections, ale niestety teraz zgubilem strone i nigdzie nie moge znalezc... W taki razie czy ktos z Was moze jednak ma 'zloty' srodek, ze temu uzytkownikowi moge zwiekszyc limit polaczen, a temu domyslnie...

 

Wiem, ze obsluguje flagi PHP, ale rowniez mogloby byc cos takiego: php_value mysql.max_user_connections 10 ale nie jestem pewny, czy taki jest wlasciwy, bo nie probowalem, ale wpis gdzies byl podobny, gdzie zmienialo sie ustawienia w .htaccess...

 

z takim uzyciem swapa nie masz wogole wolnego RAMu.

 

Mam dosyc sporo wolnego ramu, wiekszosc idzie wlasnie na buforowanie.

 

albo mocno zoptymalizujesz system (w szczegolnosci apache'a, konfiguracje php).

Prosze o dobre porady w tej sprawie, a raczej zasugerowanie gdzie moge znalezc na temat optymalizacji serwera apache, php i mysql... Bylbym wdzieczny, jezeli bedzie cos po polsku...

 

Masz racje - max_user_connections daj oczywiscie mniejsze od max_connections ale nie przesadzaj - 50 to IMO minimum.

 

Wlasnie nie moge, jak dam przy max_user_connections wiecej niz 10, chociazby 50, to serwer MySQL zapycha sie z setkami polaczeniami, tak jakby byly roboty i uruchamialy naraz kilka polaczen z jednego adresu... Moze jednak optymalizacja cos da, sam juz nie wiem...

 

Co do swapa i innych rzeczy, to zostawmy na pozniejszy czas...

 

I chcialbym zoptymalizowac Apache, php a szczegolnie MySQL, zeby byl wstanie obsluzyc conajmniej 500.000 odwolan dziennie, a nawet i wiecej, choc nie wiem ile jest teraz dokladnie, ale zasugerowalem jakas wartosc minimalna...

 

Bylbym zapomnial, co do query_cache_size, to zadna opcja mi nie dziala, mysql nie akceptuje tego, wiec musze skorzystac z innych rozwiazan...

 

I ile usluga zatrudnienia administratora w naglych przypadkach by kosztowalo? Chodzi o profesjonalizm, pewnosc, ze porzadnie zrobi...

Pozdrawiam

Łukasz

 

Wysłany Czw Lip 28, 2005 11:02 am:

 

Witam ponownie...

 

Wiec tak, czesc z Was miala racje co do niektorych polecen, wiekszosc fora, mambo masowo odrzucala polaczenia wyswietlajac blad typu: 'max users connections', wiec zwiekszalem powoli co setke i doszedlem do 900. Nie ma szans na 5, 6 czy nawet 100 polaczen na jednego uzytkownika, skoro ten parametr dotyczy konta, a nie odwiedzajacego. A wiec w ciagu pol godziny ta liczba zostala drastycznie przekroczona, zwazywszy na liczbe odwiedzin, wiec pytanie, przy opcjach timeout, wait ustawionych na 8 sekund, to jaka moze byc liczba odwolan do serwera MySQL w ciagu godziny? Mozna gdzies to sprawdzic?

 

Druga rzecz, ze podczas instalacji nowego serwera MySQL sa podane rozne pliki konfiguracyjne, w zaleznosci od mocy sprzetu i rozmiaru pamieci RAM, czyli krotko mowiac, mozna zoptymalizowac dzialanie dla RAMu o 128, 256, 512, a nawet do 4 GB, wiec wazne byl bufor, gdzie zwiekszylem do 350 MB i uspokoilo sie.

 

Ale waznym czynnikiem byl wlasnie sam serwer Apache, otoz to, w pliku konfiguracyjnym mial za duzo ustawionych aktywnych serwerow, ktore maja obsluzyc wszystkie procesy w httpd.conf, wiec drastycznie obnizylem i spokoj, minelo 20 godzin, cisza... serwer smiga bardzo ladnie, male obciazenie, ale mam male obawy, gdyz nie wiem, czy ta sytuacja moze sie powtorzyc.

 

Prosze o rade, czy w internecie sa specjalne porady jak usprawnic optymalnie serwery MySQL, Apache i php? Bo jak widze, ze na jednej stronie od dwoch tygodni w webalizer widze 1,5 mln odwolan do wszystkich plikow, a oslon 300.000, nie mowiac jeszcze o innych forach, gdzie sa podobne liczby, a nawet wiecej, to czasem wpadam w poploch, czy aby nie za duzo to nie zdrowo...

 

Month	Daily Avg	Monthly Totals

Hits	Files	Pages	Visits	Sites	KBytes	Visits	Pages	Files	Hits

Jul 2005	86260	45242	16675	749	7686	20277191	13484	300167	814366	1552695

 

Pozdrawiam serdecznie

Łukasz