Титла: На моменти mysql-а се бави много, без да има особен товар Публикувано от: abadon в Apr 22, 2010, 20:24 Здравейте,
Имам сървър със следните параметри: 4-ядрен Intel(R) Xeon(R) CPUE5504 @ 2.00GHz, SATA HDD 320 GB, 6GB RAM. На него съм инсталирал 64 bit-ово Ubuntu karmic, kernel 2.6.31-20-server, Nginx, Apache2-mpm-worker + php (fcgi), Mysql и Sendmail (default конфиг от aptitude). Nginx слуша на 80-ти порт като ми сервира статичното съдържание, запитванията за динамичното се прехвърлят към Apache на 8080. Тази конфигурация е ползвам не толкова заради производителност, колкото за предпазване от един DoS експлойт за Apache който със 8-10 К интерет и без да остави никакви следи в логовете на Apache-то е в състояние да му изяде всичките worker-и и да доведе до отказ в обслужването. На apache-то имам пуснат mod_rewrite, mod_deflate и mod_expires. Към php-то съм добавил eAccelerator ($2) и съм му пуснал gzip компресията Sendmail-а си е дефолт конфигурацията колкото да може php-тата да пращат мейли. Проблема ми е следния всичката тази конфигурация отгоре я използвам само за да ми хоства сайта ($2). Обаче забелязвам, че доста често когато имам около 100 човека онлайн изведнъж load-а на машината скача на 5 до 10 и като гледам с htop основната част от процесите виновни за това натоварване са на mysql-а. Друг път имам по 200 човека онлайн и load-а не е повече от 2. На какво може да се дължи този проблем? Как да го реша? Ето това ми е my.cnf-то: Цитат # mysqltuner.pl ми казва следното нещо: Цитат >> MySQLTuner 1.0.1 - Major Hayden <major@mhtx.net> tuning-primer.sh дава това: Цитат -- MYSQL PERFORMANCE TUNING PRIMER -- Базата данни която ползвам е с размер от около 100 МВ и към момента има 2,622,906 записа. От всичко казано до тук къде може да е проблема ми? Лоша конфигурация на mysql-а? Не ми стигат IO операциите към харда (тях не знам как да ги проверя) или пък нещо друго? Линкове към скриптовете за тест: mysqltuner.pl ($2) tuning-primer.sh ($2) Предварително благодаря! Титла: Re: На моменти mysql-а се бави много, без да има особен товар Публикувано от: borovaka в Apr 22, 2010, 21:20 Аз не мога да помогна много по въпроса. Относно performance на harda намерих това http://www.linux.com/archive/feature/131063 ($2).
Ако е от диска пробвай да ги вкараш в RAID, предполагам ще се поосвежи малко. Титла: Re: На моменти mysql-а се бави много, без да има особен товар Публикувано от: victim70 в Apr 22, 2010, 21:35 Аз не виждам грешка някаква - но болен се гласи на легло, така че копай, явно има проблем.
Провери дали коректно затваря връзките към базата скриптовете. Друг вариянт е да се логва всеки път, отваряне на сесия е ресурсоемко. Подобен проблем имах и го оправих като използвам вече отворена връзка, а ми и оставаха незатворени връзки, та и тях изчистих. Двата случая с които съм се борил и открил (друг ги реши обаче): Ефекта който наблюдавах. Работя на сървърчето с още 5 мои колеги - за 2 месеца нещата тръгваха на охлюв, рестарта ги оправяше за още един такъв период. Причина отваряне на връзки без затваряне и присъединяване на нова сесия на всяко логване. Сесията изтича а връзката не се затваря Случай 2 - 40-50 души работят на сървъра. Като влезнат всички нещата стават драматично бавно. Причината - за всяка зачвка изпълняваше login -> query -> logout. Решение persist connection. едит: Машината ти е супер едит2: Обаче 64 битовата версия вади по лошо бързодействие от 32 битовата - според някои ревюта Титла: Re: На моменти mysql-а се бави много, без да има особен товар Публикувано от: abadon в Apr 23, 2010, 14:20 @borovaka благодаря за полезния линк. Резултатите просто са плачевни:
Цитат root@www:~# hdparm -T /dev/sda Цитат root@www:~# fio random-read-test.fio Не знам ти как смяташ но аз смятам че този хард на сървъра е боклук, като сравнявам резултатите си със лаптопа ми Acer Aspire 4810TZ ($2) Модела ми е със 4GB ram и под оправлението на същата OS като на сървъра, само kernela ми е 2.6.31-20-generic. Резултатите: Цитат root@abadon:~# hdparm -T /dev/sda Цитат root@abadon:~# fio random-read-test.fio Дали от вида на файловата система и начина на монтиране може да се получава такава голяма разлика? На лаптопа ми файловата система е reiserfs без LVM монтирана натака: Цитат # / was on /dev/sda5 during installation А на сървъра е reiserfs със LVM монтирана така: Цитат /dev/mapper/storage-root / reiserfs noatime,notail,defaults 0 1 @victim70 Не съм разглеждал твоите съвети подробно все още, но не ползвам пернаментни връзки към mysql-а. Ще ги разгледам като отстраня горния проблем. Титла: Re: На моменти mysql-а се бави много, без да има особен товар Публикувано от: tolostoi в Apr 23, 2010, 16:43 Прекалено бавен изглежда харда (не зная дали hdparm е нещо на което може да се разчита и дали по време на теста диска не е много натоварен с друго), прегледай кернел лога дали не плюе грешки, не ти е от лвм-то. Ето при мен изход и то от обединени 2 райд1 масива в един Volume group
Код: hdparm -t /dev/mapper/first-samba Мисля, че ти имаше и друга тема с мъка по mysql-a, май най-добре ще е да погледнете с някои който разбира какви куерита прави и да се оптимизира ако е възможно. Титла: Re: На моменти mysql-а се бави много, без да има особен товар Публикувано от: borovaka в Apr 23, 2010, 17:46 Защо не пробваш с RAID масив. Би трябвало да се подобрят нещата с бързодействието.
А относно lvm не вярвам да ти създава проблем поне до сега аз съм нямал такъв, само ми е улеснявало живота :) Титла: Re: На моменти mysql-а се бави много, без да има особен товар Публикувано от: abadon в Apr 23, 2010, 19:57 @tolostoi Да преди бях пускал също тема за бавен mysql, но тогава още не бях намерил двата скрипта за оптимизация, към които съм дал линкове в първия си пост. И по важното тогава mysql-а беше на виртуална машина със 256МВ ram, харда ми беше 8GB и нямах сведения виртуалното CPU колко ползва от реалното на хипервайзора. Иначе и на мен ми се вижда страшно бавен харда, тъй като и на теста с fio който ми се вижда по-достоверен резултата е лош. Ето hdparm пуснат на виртуална машина с LVM хоствнана на vmware ESXi 3.5 с локален сторидж върху RAID-5 масив.
Цитат hdparm -t /dev/mapper/storage Гледам hdparm-а го пускаш срещу LVM-а не към харда защото имам сериозна разлика между двете, което не знам дали е нормално? Цитат oot@www:~# hdparm -t /dev/mapper/storage-root В LVM-а имам само този хард. @borovaka май към RAID отива работата, макар че преди да стигна до там искам да извлека всичко, което мога от наличния хардуер. Тъй като за райда си трябват и още не малко пари за хардуер, които към момента нямам. Днес докато си мислех как да разреша проблема стигнах до това решение дали може да се реализира или е само моя фантазия? Тъй като базата ми данни е около 100 МВ и нараства със 2-3 МВ на ден има ли вариант да накарам mysql-а да не пише по харда? Смисъл сега да load-не в RAM-а тези 100 МВ база и да си я държи само в RAM-а като примерно нощем когато нямам натоварване да правя по един dump на харда. С цел ако огасне тока да не загубя цялата информацията а да загубя само не запазеното на харда. Дали може да се направи такава конфигурация? Титла: Re: На моменти mysql-а се бави много, без да има особен товар Публикувано от: nemanema в Apr 23, 2010, 20:02 Цитат root@www:~# hdparm -T /dev/sda Здрасти, не че му разбирам на Ubuntu, но ако цитираните показатели на диска са точни, мога да кажа само едно много лоша организация на ОС и файлова структура. Относно проблема с лоудинга на машината, очевидно е страданието за дисков тракт. Или да се смени дисковият масив с адекватен (примерно 4 х Seagate 15k.7 RAID 10 или 2 x Intel X25-SLC RAID 1 за базата данни) или да се направи масив от много (поне 8) малки по обем но "пъргави" SATA2 дискове в RAID 10 в малък размер на парчетата за слепване и за разпределяне (е няма добро българско обяснение с малко думи "stripe size"). Успех ! П.П. като си се сдобивал с машината защо не си предвидил натоварването на дисковият тракт ? Титла: Re: На моменти mysql-а се бави много, без да има особен товар Публикувано от: borovaka в Apr 23, 2010, 23:13 abadon май има начин да се осъществи това. Аз си нямам идея от mysql но това ми изглежда като решение на това което си замислил:
http://dev.mysql.com/doc/refman/5.0/en/memory-storage-engine.html ($2) Дано ти помогне. Титла: Re: На моменти mysql-а се бави много, без да има особен товар Публикувано от: abscent в Apr 24, 2010, 18:17 И аз да взема да взема участие в тази тема, макар и малко позакъсняло :)
Като цяло натоварването на диска (т.е. I/O-операциите) могат много удобно да се видят с инструмента iotop - показва в реално време (през определен интервал все пак) кой процес с каква скорост в коя директория пише/чете. Би трябвало да го има в хранилищата на debian - в gentoo се компилира с emerge iotop, няма някакви големи зависимости от други пакети. По отношение на въпроса как да се монтира директорията, в която пише mysql-демона - идеята е да може да се монтира директория като tmpfs-файлова система (man mount - низ tmpfs), и периодично през cron да се синхронизира съдържанието на директорията с базата данни, която си 'почива' на диска... дано да стане ясно какво имам предвид, ако има нужда, мога да поясня Титла: Re: На моменти mysql-а се бави много, без да има особен товар Публикувано от: abadon в Apr 25, 2010, 14:48 @borovaka Благодаря за линка ще го разгледам и ще пиша какъв е бил резултата.
@abscent благодаря за полезния инструмент iotop! Относно идеята ти за mysql-а ако разбирам правилно създавам си една tmpfs файлова система която се разполага в рама, след което я монтирам примерно в /tmpfs и казвам на mysql-а че работната му директория е примерно /tmpfs/mysql след което през cron-а копирам всички файлове от /tmpfs/mysql примерно в /var/mysql Това ли е идята? Така няма ли някой файлове от /tmpfs/mysql да не могат да се копират защото се използват? Титла: Re: На моменти mysql-а се бави много, без да има особен товар Публикувано от: abadon в Apr 26, 2010, 14:50 Полуфинално нещата ги направих така:
1. Създадох върху автоматично монтираната ми от Ubuntu-то tmpfs, като /dev/shm следните две директории: Цитат # mkdir /dev/shm/mysql Ако ползвате дистрибуция която не монтира автоматично tmpfs файлова система. Може да си монтирате такава по следния начин: Цитат # mkdir -p /mnt/tmp В /etc/fstab се описва по този начин: Цитат tmpfs /mnt/tmp tmpfs size=256M,mode=0777 0 0 2. Новосъздадените директории ги направих собственост на mysql. Посредством тези команди: Цитат # chown mysql:mysql /dev/shm/mysql/3. Редактирах my.cnf-то, като промених тези два параметъра datadir и tmpdir. В моят случай така: Цитат datadir = /dev/shm/mysql4. За да нямам проблеми с apparmor-а във файла /etc/apparmor.d/usr.sbin.mysqld добавих следните редове: Цитат # Give access of mysql to use /dev/shm Ако не се ползва apparmor тази стъпка не е нужна. Ако някой ползва SELinux трябва да извърши еквивалента на тази конфигурация само че за SELinux. 5. Спрях mysql сървъра: Цитат /etc/init.d/mysql stop6. Копирах всички файлове на mysql-а от харда във рама: Цитат cp -ar /var/lib/mysql/* /dev/shm/mysql/7. Стартирах отново mysql сървъра: Цитат /etc/init.d/mysql start Воала базата ми данни тръгна доста по-бързо! ;) От тук насам вече почват тънките моменти. Трябва да се има предвид, че при рестарт на машината цялата информация от /dev/shm ще изчезне! Затова периодично през cron-а в ненатоварените моменти пускам този "скрипт" mysqlbackup-shm.sh : Цитат # /bin/sh който ми синхронизира RAM-а със хардиска. Плюс са по голяма сигурност си пускам и всяка нощ Automysqlbackup.sh ($2) И за да съм абсолютно сигурен, че нищо няма да се намаже, преди рестарт на машината бих препоръчал извършването на стъпка 5 и пускането на mysqlbackup-shm.sh След като машината се стартира отново за да не се повтарят горните стъпки може да се пусне mysql-on-tmpfs.sh: Цитат # /bin/bash Дано съм бил полезен и на някой друг който е решил да пусне mysql върху tmpfs Молбата ми е ако има някой по-добър с bash-а и със init скриптовете да каже как може да се направи автоматично при shutdown/reboot на машината де се изпълнява стъпка 5 и mysqlbackup-shm.sh. Респективно при стартиране да се изпълнява mysql-on-tmpfs.sh след което да се стартира автоматично mysql сървъра. Титла: Re: На моменти mysql-а се бави много, без да има особен товар Публикувано от: Naka в Apr 26, 2010, 17:38 Без да съм чел всичко подробно в поста, искам да споделя моят опит.
Виждал съм такова разваляне на хард. Скоростта на трансфер пада от 60-70MB/Sec до 2-3 Мб/Sec. Като всичко друго с харда е наред: Няма лоши сектори, няма развалени данни, няма проблеми. Приложенията работят без грешка, само дето много се кумят като се обръщат към диска. проблема се виждаше само чрез hdparm -t /dev/xxxxx, A диска беше Maxtor 20Gb. Пусни резултата от smartctl --all /dev/sda Пускаш едно LiveCD тестваш с hdparm (или sdparm?) и ако даде 2-3 MB/sec (под 10) можеш да хвърлиш харда. добре е да закачиш и друг диск на този кабел да видиш дали не е нещо от чипсета. или пък този диск го тествай за скорост на друг компютър. Цитат Здрасти, не че му разбирам на Ubuntu, но ако цитираните показатели на диска са точни, мога да кажа само едно много лоша организация на ОС и файлова структура.Показанията на hdparm -t върху физически диск, не зависят от файловата структура. |