MySQL - Linux vs FreeBSD
6 отговора
329 прегледа
MySQL - Linux vs FreeBSD
Доста дискутирана тема е под коя от двете OS MySQL работи по-добре.
Изводите в крайна сметка се свеждат до следното:
(Имам предвид мнение, с което доста познавачи са съгласни включително и от екипа на MySQL)
FreeBSD дава по-добро производителност при 1 CPU
При > 1 CPU - SMP Linux има предимство
Причината: MySQL използва threads, които Linux-2.2.x и 2.4.x разпределят върху процесорите докато FreeBSD използва само 1 процесор.
Срещал съм също добре аргументираното твърдение, че най-добрата платформа за MySQL e SPARC
Имате ли някакви наблюдения по въпроса?
Все пак вече и в България се срещат SMP машини :)
Linux is like a wigwam - No Windows, No Gates, Apache inside
Изводите в крайна сметка се свеждат до следното:
(Имам предвид мнение, с което доста познавачи са съгласни включително и от екипа на MySQL)
FreeBSD дава по-добро производителност при 1 CPU
При > 1 CPU - SMP Linux има предимство
Причината: MySQL използва threads, които Linux-2.2.x и 2.4.x разпределят върху процесорите докато FreeBSD използва само 1 процесор.
Срещал съм също добре аргументираното твърдение, че най-добрата платформа за MySQL e SPARC
Имате ли някакви наблюдения по въпроса?
Все пак вече и в България се срещат SMP машини :)
Linux is like a wigwam - No Windows, No Gates, Apache inside
Re: salle kazi neshto za NT i win98
Не съм си и помислял да пускам mysql под Win :)
Според мен WinNT е чудесна работна станция и изобщо не става за сървър.
И тъй като mysql е sql сървър ....
А за неща които не съм пробвал предпочитам да не говоря.
Linux is like a wigwam - No Windows, No Gates, Apache inside
Според мен WinNT е чудесна работна станция и изобщо не става за сървър.
И тъй като mysql е sql сървър ....
А за неща които не съм пробвал предпочитам да не говоря.
Linux is like a wigwam - No Windows, No Gates, Apache inside
Re: MySQL - Linux vs FreeBSD
FreeBSD ot baq vreme poddurja SMP, kakto i sobstveni threads. V toq smisul ne e vqrno che FreeBSD s MySQL na SMP mashina shte ispolzva samo 1-to CPU!!!
Za performance e otnositelno, trqbva da se testva. Specialno MySQL moje da se kompilira na freebsd s poddrujka na linux threads.
Po moe mnenie mysql-a e po-pretenciozen kum RAM-a. V momenta ima CPU-ta na nad 1GHz, taka che shte mu stigne i na 1-no cpu:)
A inache, SMP machini ima, ama mnogo debelo za lichen PC :(
Za performance e otnositelno, trqbva da se testva. Specialno MySQL moje da se kompilira na freebsd s poddrujka na linux threads.
Po moe mnenie mysql-a e po-pretenciozen kum RAM-a. V momenta ima CPU-ta na nad 1GHz, taka che shte mu stigne i na 1-no cpu:)
A inache, SMP machini ima, ama mnogo debelo za lichen PC :(
Re: MySQL - Linux vs FreeBSD
Neshto pofe4e, pri FreeBSD RELENG_4...ergh, 4.x :)
threads, po-to4no POSIX threads sa native, za razlika ot linuxthreads
i spored men, rabotqt dosta po-dobre ot linux threads, tfa e samo moe mnenie, a ne tfyrdenie :>
F interes na istinata, SQL-a nezafisi kyf e, po-dobre da go runfash na SCSI hdd i 1 CPU, otkolkoto (E)IDE i 4 CPU-ta :P
e ako ima i pofe4ko ram, syshto ne e losho :>
rgdz
curly
threads, po-to4no POSIX threads sa native, za razlika ot linuxthreads
i spored men, rabotqt dosta po-dobre ot linux threads, tfa e samo moe mnenie, a ne tfyrdenie :>
F interes na istinata, SQL-a nezafisi kyf e, po-dobre da go runfash na SCSI hdd i 1 CPU, otkolkoto (E)IDE i 4 CPU-ta :P
e ako ima i pofe4ko ram, syshto ne e losho :>
rgdz
curly
Re: MySQL - Linux vs FreeBSD
Хмм....
И двамата не сте прави
1. Не става въпрос за това коя OS по-добре използва SMP а за това, че MySQL под FreeBSD както и да се компилира пуска всички threads на 1 CPU докато на Linux ги разпределя.
2. Аз не си мисля така - не съм имал възможност да тествам. Цитирам хора, които са правили тестове вкл. Jeremy Cole - чонек от екипа на MySQL, който описваше доста натоварен негов сървър - около 1.6 милиона заявки на час - PHP сесии - т.е. SELECT + INSERT. Та на въпроса защо 4CPU - Xeon машината му е под Linux а не FreeBSD последва доста дълго обяснение подкрепено от o,whr фенове на FreeBSD.
3. Въпроса за хардуера също е малко спорен защото силно зависи от натоварването. Има огромна разлика между 1 клиент който пише и 1 чете и 100 едновременно пишещи и 1000 едновременно четящи. В първия случай (1 log-ващ daemon) едва ли има смисъл от >1 CPU - max 2 за да може втория да чете. Във втория случай ..... Всъщност MySQL не е особено подходящ когато има много едновременно ъпдейтващи клиенти.
Като цяло пътя за оптимизация е:
Повече RAM, повече CPU, по-бързи дискове
В този точно ред. Това обаче важи за всички SQL сървъри доколкото знам.
Нещо специфично за MySQL и не толкова лесно за намиране в документацията:
my.cnf
[mysqld]
...
tmpdir = /mysqltmp
log-update = /mysql_log/update.log
Тези двете се слагат на ФИЗИЧЕСКИ различен диск от datadir
т.е. базите данни, log и tmp се разхвърлят върху различни дискове - ясно е откъде се печели скорост.
Също така могат да се разхвърлят отделни бази данни и дори отделни таблици.
MySQL се работи без прроблеми със symlink
така, че ако имате натоварена таблица може дори да разделите .MYD от .MYI
на 2 IDE-та и да спечелите повече скорост от 1 SCSI
Естествено 5 SCSI диска винаги ще са по-бързи :)))
Всичко това е свързано с не толкова очевидния факт (и не особено логичен), че MySQL пише част от Temp таблиците във tmpdir а други във директорията на съответната база данни.
Примерно ALTER TABLE DROP KEY key; създава временна таблица в същата директория. SELECT .... FROM ... GROUP BY ... ORDER BY ... DESC; създава временна таблица във tmpdir !!! А това може да бъде проблем както с достатъчно празно място така и като сигурност. tmpdir по default е /tmp а там обикновено имат достъп всички..
Linux is like a wigwam - No Windows, No Gates, Apache inside
И двамата не сте прави
1. Не става въпрос за това коя OS по-добре използва SMP а за това, че MySQL под FreeBSD както и да се компилира пуска всички threads на 1 CPU докато на Linux ги разпределя.
2. Аз не си мисля така - не съм имал възможност да тествам. Цитирам хора, които са правили тестове вкл. Jeremy Cole - чонек от екипа на MySQL, който описваше доста натоварен негов сървър - около 1.6 милиона заявки на час - PHP сесии - т.е. SELECT + INSERT. Та на въпроса защо 4CPU - Xeon машината му е под Linux а не FreeBSD последва доста дълго обяснение подкрепено от o,whr фенове на FreeBSD.
3. Въпроса за хардуера също е малко спорен защото силно зависи от натоварването. Има огромна разлика между 1 клиент който пише и 1 чете и 100 едновременно пишещи и 1000 едновременно четящи. В първия случай (1 log-ващ daemon) едва ли има смисъл от >1 CPU - max 2 за да може втория да чете. Във втория случай ..... Всъщност MySQL не е особено подходящ когато има много едновременно ъпдейтващи клиенти.
Като цяло пътя за оптимизация е:
Повече RAM, повече CPU, по-бързи дискове
В този точно ред. Това обаче важи за всички SQL сървъри доколкото знам.
Нещо специфично за MySQL и не толкова лесно за намиране в документацията:
my.cnf
[mysqld]
...
tmpdir = /mysqltmp
log-update = /mysql_log/update.log
Тези двете се слагат на ФИЗИЧЕСКИ различен диск от datadir
т.е. базите данни, log и tmp се разхвърлят върху различни дискове - ясно е откъде се печели скорост.
Също така могат да се разхвърлят отделни бази данни и дори отделни таблици.
MySQL се работи без прроблеми със symlink
така, че ако имате натоварена таблица може дори да разделите .MYD от .MYI
на 2 IDE-та и да спечелите повече скорост от 1 SCSI
Естествено 5 SCSI диска винаги ще са по-бързи :)))
Всичко това е свързано с не толкова очевидния факт (и не особено логичен), че MySQL пише част от Temp таблиците във tmpdir а други във директорията на съответната база данни.
Примерно ALTER TABLE DROP KEY key; създава временна таблица в същата директория. SELECT .... FROM ... GROUP BY ... ORDER BY ... DESC; създава временна таблица във tmpdir !!! А това може да бъде проблем както с достатъчно празно място така и като сигурност. tmpdir по default е /tmp а там обикновено имат достъп всички..
Linux is like a wigwam - No Windows, No Gates, Apache inside