Hello all, Am o problema cu un server. Acum cateva zile a luat un update de mysql (sunt pe centos5, toate update-urile la zi). Pe el rulez un squid cu pam_auth via mysql. De atunci, vad ca serverul ramane constant fara memorie, iar cu top vad pam_auth ca se duce 30-40% din CPU si 80-90%-100% din memorie (2GB/RAM+2GB/SWAP).
Pam_auth paseaza query-uri de validare user/pass in mysql. Totul a mers impecabil pana inainte de acest update la mysql-5.0.77-3. In afara de operatii de tip select, pam_auth nu face altceva. Sapand in logurile mysql, am gasit mesajul: 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295 Deci dupa update, nu i-a placut valoare lui max_join_size si a pus-o pe default (4294967295). Care o fi diferenta intre default-ul din versiunea mysql-5.0.77 si versiunile anterioare mysql-5.0.xx, nu am reusit sa aflu. Am incercat sa o reduc aceasta valoare dar nu ajuta, pam_auth tine in continuare memoria sus cu selecturile in mysql. Adaugarea de memoria suplimentara swap (de la 2 la 4GB), nu a rezolvat problema. Deocamdata, am facut un script care monitorizeaza swap-ul si da restart la squid. Dupa restart, totul reintra in normal pentru 30-40 de minute, cand utilizarea memoriei creste lent dar sigur pana la o valoare peste care nu il mai las eu si-i dau restart la squid. am verificat si numarul de conexiuni la baza de date si aici totul e normal (max_connections=500, max_used_connections=23). Cred ca e ceva schimbat prin bufferele de la mysql de se sufoca, dar nu prea ma prind pe unde trebuie sa umblu. desi nu e cazul (eu am o tabela sql cu cateva zeci de linii) am verificat si sql_big_selects este pe ON. Am facut si downgrade la mysql (versiunea mysql-5.0.45) dar vad ca problema se mentine. ultimul dump cu baza de date sql vad ca este facut cu mysql si mai vechi (5.0.22). Pe versiunea aia sunt 100% ca nu am avut nici un fel de problema asa ca inainte de a face un restore la intregul serverul as vrea sa stiu cam pe unde mai pot umbla. mysql> SHOW vARIABLES like '%size%'; +---------------------------------+------------+ | Variable_name | Value | +---------------------------------+------------+ | bdb_cache_size | 8388600 | | bdb_log_buffer_size | 32768 | | binlog_cache_size | 32768 | | bulk_insert_buffer_size | 8388608 | | delayed_queue_size | 1000 | | innodb_additional_mem_pool_size | 1048576 | | innodb_buffer_pool_size | 8388608 | | innodb_log_buffer_size | 1048576 | | innodb_log_file_size | 5242880 | | join_buffer_size | 131072 | | key_buffer_size | 8388600 | | key_cache_block_size | 1024 | | large_page_size | 0 | | max_binlog_cache_size | 4294967295 | | max_binlog_size | 1073741824 | | max_heap_table_size | 16777216 | | max_join_size | 4294967295 | | max_relay_log_size | 0 | | myisam_data_pointer_size | 6 | | myisam_max_sort_file_size | 2147483647 | | myisam_sort_buffer_size | 8388608 | | preload_buffer_size | 32768 | | profiling_history_size | 15 | | query_alloc_block_size | 8192 | | query_cache_size | 0 | | query_prealloc_size | 8192 | | range_alloc_block_size | 2048 | | read_buffer_size | 131072 | | read_rnd_buffer_size | 262144 | | sort_buffer_size | 2097144 | | thread_cache_size | 0 | | tmp_table_size | 33554432 | | transaction_alloc_block_size | 8192 | | transaction_prealloc_size | 4096 | +---------------------------------+------------+ 34 rows in set (0.03 sec) Hdd-ul l-am verificat, nu are badblocks si memoria RAM e noua (cumparata acum cateva luni). Mersi, Alx _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
