Comments 105
Плотность полезных ссылок и советов в посте зашкаливает :) спасибо.
Из-за природной скромности автора топика хочу отметить для желающих выразить свою благодарность на следующий его твит:
Куда бы устроиться только что одипломившемуся студенту, так чтоб колектив хороший, работа интересная и с зарплатой не обижали?
Статья и в самом деле отличная! У меня аж голова заболела от налетевшего объёма информации!!!
блин, ну выбирайте нормальные хостинги для картинок.
«уже давно покорится на какой-нить немецкой, свалке»
вероятно, покоится? :)
вероятно, покоится? :)
Автору респект — пост весьма информативен и полезен.
В избранном.
В избранном.
Супер! Огромное спасибо! Я как раз пытаюсь разобраться как бы пооптимальнее настроить свой простенький VPS. В скором времени предстоит контролировать большой проект на взрослом хостинге.
Жаль нельзя отдать все 100 плюсов к карме, которые валяются без дела )8
Жаль нельзя отдать все 100 плюсов к карме, которые валяются без дела )8
Ну наконец-то действительно полезный топик среди тонн копипаста и уг. Спасибо, в избранное.
Насчёт «4.4 Кодировки» думаю заморачиватся не стоит, 1251 прошлый век и сайтов на нём всё меньше и меньше.
Насчёт «4.4 Кодировки» думаю заморачиватся не стоит, 1251 прошлый век и сайтов на нём всё меньше и меньше.
Вы правы, ибо наш баг bugs.mysql.com/bug.php?id=46622 является прямым следствием использования cp1251. А память нынче очень дешёвая и ради удобства лучше юзать UTF-8
Однако если бы у нас было utf8 наша база перестала бы влезать в оперативку ещё полгода назад. Так что пока не накопим денег на «не арендный» сервак, поживём пока на windows-1251
Однако если бы у нас было utf8 наша база перестала бы влезать в оперативку ещё полгода назад. Так что пока не накопим денег на «не арендный» сервак, поживём пока на windows-1251
Поддерживаю. Использование UTF-8 позволяет попросту забыть, что такое кодировка. Душевное спокойствие важнее, чем экономия места.
Эээ а я вот слышал что использование утф8 вызывает проблем при вставке BLOB'ов в MySQL-запросе.
Наконец-то полезный технический пост! Действительно хабр сейчас стал сраным пристанищем копипастеров новостей про крутые блоки питания и нытиков, а появляющиеся новые статьи практически не содержат полезного технического контента.
Потому что горадо легче кинуть копипаст, чем написать хорошую полезную статью.
Потому что горадо легче кинуть копипаст, чем написать хорошую полезную статью.
Согласен. Читать по кругу «Гаджеты», «Apple», ".NET", уже изрядно надоело. Гораздо больше надоели «параноик-потс» о том, что интернет будет под контролем ZOG^W МВД или Google не удаляет персональные данные.
Автору, естественно, плюс.
Автору, естественно, плюс.
Посмотрите посещемость хабра за последние полгода на какой-нибудь алексе.
Если учесть, что большинство из людей, имеющих нормальную квалификацию и желание писать, уже давно на хабре, понятно что это за вновь поступивший контингент в подавляющем большинстве. Попса.
Оно в принципе и ничего бы, но эта свора отбивает желание у нормальных людей писать нормальные статьи. Раньше практически каждый день хотя бы одна сильная статья, но была. Сейчас в неделю две-три…
Для проекта это возможно и к лучшему (посещаемость, монетизация и т.п.), для желающих читать серьезные статьи — жопа.
Если учесть, что большинство из людей, имеющих нормальную квалификацию и желание писать, уже давно на хабре, понятно что это за вновь поступивший контингент в подавляющем большинстве. Попса.
Оно в принципе и ничего бы, но эта свора отбивает желание у нормальных людей писать нормальные статьи. Раньше практически каждый день хотя бы одна сильная статья, но была. Сейчас в неделю две-три…
Для проекта это возможно и к лучшему (посещаемость, монетизация и т.п.), для желающих читать серьезные статьи — жопа.
Да автор проделал большую работу. Большое ему за это спасибо. Очень много полезного. По-больше бы таких статей.
Идеальный пост для хабры! Лучше не придумаешь.
Большое вам спасибо за статью.
Большое вам спасибо за статью.
Большое спасибо. Хотя, если говорить о тотальной оптимизации бэкенда, нельзя упускать оптимизацию кода на PHP, это касается и низкоуровневой оптимизации синтаксиса, например конструкция $tmp = $Array[«key»] работает в пару раз быструу аналогичной $tmp = $Array['key'] и на порядок быстрее $tmp = $Array[key] (речь об ассоциативных массивах, типа («key»=> «value»)), и оптимизации алгоритмов, например использования памяти и т.д.
сколько раз уже говорили, что менять for на foreach — это песочница, а не оптимизация
$tmp = $Array['key'] будет быстрее, это так, для справочки.
Спасибо, открыл старые тесты производительности и да, Вы правы. Значит у меня уже крыша едет…
В том то и дело, что они старые.
Если у вас $tmp = $Array[«key»] не парсится на каждой итерации — разницы между 'key' и «key» никакой.
P.S.
Часто вижу ссылки на статью www php spb ru /php/speed.html, которая не изменялась более 6 лет. Это уже давно не так…
Если у вас $tmp = $Array[«key»] не парсится на каждой итерации — разницы между 'key' и «key» никакой.
P.S.
Часто вижу ссылки на статью www php spb ru /php/speed.html, которая не изменялась более 6 лет. Это уже давно не так…
У вас крыша едет если вы занимаетесь подобной «оптимизацией» :)
Никак не могу найти работающий пример кэширования fastcgi_cache для гостей (coockies).
Сильно…
> Однако, посмотрев на список deprecated функций в 5.3 можно ужаснутся, благо они пока ещё работают.
Имхо только dl() из них полезная, да и то на шаред хостингах, где ее обычно запрещают.
Имхо только dl() из них полезная, да и то на шаред хостингах, где ее обычно запрещают.
хорошая обзорная статья, пишите еще
Вы софт на FreeBSD ставили из портов или пакетов?
Если позаморачиваться с флагами сборки софта для портов, то есть шанс ещё немного (а может даже много) выиграть.
Если позаморачиваться с флагами сборки софта для портов, то есть шанс ещё немного (а может даже много) выиграть.
Правильные оптимизации могут дать очень хороший выход по производительности. Но там тоже нужно аккуратно — перестаравшись легко потерять стабильность или даже затормозить систему.
Да, всё из портов, что-то из svn/git/etc. С флагами всё немного сложнее: -O3 бывает бъёт приложения, а CPUTYPE может заставить нас пересобирать целиком систему после смены CPU.
Тут нужно очень индивидуально подходить, тот же XBTT у нас например с -O3 собран, а какойто софт наоборот может даже быстрее с -Os работать.
Хорошее описалово по оптимизациям gcc есть тут
Тут нужно очень индивидуально подходить, тот же XBTT у нас например с -O3 собран, а какойто софт наоборот может даже быстрее с -Os работать.
Хорошее описалово по оптимизациям gcc есть тут
> Выходом из такой ситуации являлось бы либо хранение глобальных переменных в opcode cacher'e типа APC/eAccelerator.
Разве в eAccelerator можно хранить свои данные по подобию APC?
Я с удовольствием заюзал бы APC, если бы не:
pecl.php.net/bugs/bug.php?id=16787
pecl.php.net/bugs/bug.php?id=16814
Разве в eAccelerator можно хранить свои данные по подобию APC?
Я с удовольствием заюзал бы APC, если бы не:
pecl.php.net/bugs/bug.php?id=16787
pecl.php.net/bugs/bug.php?id=16814
Можно: bart.eaccelerator.net/doc/phpdoc/eAccelerator/_shared_memory_php.html#functioneaccelerator_put
Хотя я давно его заменил на xcache.
Хотя я давно его заменил на xcache.
Есть еще проблема акселераторов, если проект динамично разрабатываемый, и у него несколько бекенд-серверов, то укатка кода на продакшн проходит неравномерно.
Заметки:
>1.6 Softupdates, gjournal и mount options
это приводит к падению производительности, куда лучше smartups + скрипт корректно гасящий сервер при выключении питания
>4.1.2 Переход на InnoDB
myisam можно починить, если ломается innodb — только восстановление с бекапа
В целом — очень полный обзор, хотя по оптимизации ядра и включения там нужных плюшек — мало сказано
>1.6 Softupdates, gjournal и mount options
это приводит к падению производительности, куда лучше smartups + скрипт корректно гасящий сервер при выключении питания
>4.1.2 Переход на InnoDB
myisam можно починить, если ломается innodb — только восстановление с бекапа
В целом — очень полный обзор, хотя по оптимизации ядра и включения там нужных плюшек — мало сказано
по поводу innodb вы не правы — его можно восстановить если есть бинарный лог запросов.
Так-же как из бекапа — дроп и восстановление дампа?
в автоматическом режиме dev.mysql.com/doc/refman/5.0/en/innodb-backup.html
откатывает незавершенные транзакции на момент падения, это даже с отключенными бинарными логами.
А с бинарными логами подобное можно сделать с контрольной точки, в них лог всех действий в базе.
Поднятие из дампа только в случае физического повреждения данных, ну или с холодного бекапа, смотря что применялось. Плюс при наличии бинарных логов, можно восстановиться до последней успешной транзакции перед падением.
Механизм схож с тем, что делает Оракл в случае «неожиданной» остановки, что в общем то и не удивительно =)
откатывает незавершенные транзакции на момент падения, это даже с отключенными бинарными логами.
А с бинарными логами подобное можно сделать с контрольной точки, в них лог всех действий в базе.
Поднятие из дампа только в случае физического повреждения данных, ну или с холодного бекапа, смотря что применялось. Плюс при наличии бинарных логов, можно восстановиться до последней успешной транзакции перед падением.
Механизм схож с тем, что делает Оракл в случае «неожиданной» остановки, что в общем то и не удивительно =)
Хотел бы добавить, что nginx можно использовать для отдачи данных сразу из мемкэша. Для тех страниц которые можно кэшировать целиком, бывает очень полезно.
Насчет myisam, это нормальный движек, просто в большинстве случаев его используют так как он является дефолтным. А его использовать нужно только если точно знаешь, что не нужны транзакции и не будет insert/select по одной таблице таблице. Для таблиц где только SELECT'ы бегают может быть быстрее InnoDB. Кроме этого не завбывает про замечательный движек ARCHIVE который можно использовать для таблиц с логами.
Насчет myisam, это нормальный движек, просто в большинстве случаев его используют так как он является дефолтным. А его использовать нужно только если точно знаешь, что не нужны транзакции и не будет insert/select по одной таблице таблице. Для таблиц где только SELECT'ы бегают может быть быстрее InnoDB. Кроме этого не завбывает про замечательный движек ARCHIVE который можно использовать для таблиц с логами.
UFO just landed and posted this here
Эта заметка должна войти в золотой фонд хабры, я считаю.
спасибо большое за такое количество полезной информации в одном месте )
Написано добротно, но. Меня смущает FreeBSD на серверах DB.
Файловая система фри ой как желает лутшего. У меня в тестах получалось 20-30% UFS vs. Ext3. А ну и тридинг во фре немного лажает.
Автор написал что у него бекенд ето PHP — я так понял что PHP как fcgi работает. Или все таки там есть апач? По моих замерах производительность nginx+php на 25-30% хуже чем в apache в позе mpm_worker'а. Ну ето если не компилить php-код каким-то roadsend'ом.
Файловая система фри ой как желает лутшего. У меня в тестах получалось 20-30% UFS vs. Ext3. А ну и тридинг во фре немного лажает.
Автор написал что у него бекенд ето PHP — я так понял что PHP как fcgi работает. Или все таки там есть апач? По моих замерах производительность nginx+php на 25-30% хуже чем в apache в позе mpm_worker'а. Ну ето если не компилить php-код каким-то roadsend'ом.
> производительность nginx+php на 25-30% хуже чем в apache в позе mpm_worker'а
Это вы как считали, что nginx оказался медленнее apache?
Можно технологию тестирования и результаты? Интересно…
Это вы как считали, что nginx оказался медленнее apache?
Можно технологию тестирования и результаты? Интересно…
В окружении nginx отдавал всю статику на отдельних доменах. Тест базировался на том, что _только_ php код hi-load проекта обрабативался:
а) nginx + fastcgi + php
b) apache(mpm_worker) + zts threading php.
а) nginx + fastcgi + php
b) apache(mpm_worker) + zts threading php.
Гм. А php-fpm тестировали? Или каким образом спавнились fcgi?
И тюнился ли сам PHP?
И тюнился ли сам PHP?
На тот момент php-fpm был в аццкой альфе и не прошел даже пре тестинг, ну и вообще, IMHO, патчить софт с коробки для большого продакшена — зло.
PHP тюнился на уровне отключения ненужного, ну и php.ini ондеманд :)
PHP тюнился на уровне отключения ненужного, ну и php.ini ондеманд :)
Технология тестирования — скрипт для форкинга ab на рандом URL'. Интересовала отдача. Результатов сейчас не наведу — остались на пошлой работе :)
Не согласен с «тридинг во фре немного лажает». Шедулер отлаживался и был несколько неадекватен в версиях 5.х, когда делали нормальную поддержку SMP. В 7.х он уже очень даже хорош.
Про 20-30% UFS vs. Ext3 не верю. Последняя быстрее, но не с таким отрывом.
Кроме того, автор упомянул ZFS.
Про 20-30% UFS vs. Ext3 не верю. Последняя быстрее, но не с таким отрывом.
Кроме того, автор упомянул ZFS.
Для сравнения попробуйте какой то тридинг-mpm в апаче под нагруженной BSD и увидите о чем я. Вижу тема интересная, попробую в лабе сделать свежий тест.
Относительно fs то в линуксе шедулер юзал и deadline и noop, правда, на не совсем обычном IBM Blade HS21 + IBM FC Storage DS 4700. Может настолько большая разница из за недоделанности дров для BSD.
Относительно fs то в линуксе шедулер юзал и deadline и noop, правда, на не совсем обычном IBM Blade HS21 + IBM FC Storage DS 4700. Может настолько большая разница из за недоделанности дров для BSD.
SaveTheRbtz, на счёт fstab:
1. async — это использование оперативки для кэша, а BPU помогает сохранить кэш в RAID устройстве, но не в оперативке.
2. Вместо noatime рекомендуется всё же relatime, т.к. есть некоторый софт, который ориентируется на atime и может неверно работать с noatime.
1. async — это использование оперативки для кэша, а BPU помогает сохранить кэш в RAID устройстве, но не в оперативке.
2. Вместо noatime рекомендуется всё же relatime, т.к. есть некоторый софт, который ориентируется на atime и может неверно работать с noatime.
хм… InnoDB имеет ряд преимуществ и ряд недостатков.
Лично для меня основное преимущество — блокировки на уровне строки. Тоесть при большом количестве одновременных UPDATE,INSERT не получим столько блокировок таблиц, как на myisam.
Но InnoDB нельзя срезать бинарно. И это для меня был самый большой минус. Так как таблицы были огромными и гигантские дампы не доставляли радости. Особенно, если при разворачивании дампа закрадывалась ошибка в файле…
Потому, не стоит рекомендовать всем использовать InnoDB. Надо использовать именно тот storage engine, который подходит твоему проекту, твоей структуре БД и твоим запросам к БД.
Лично для меня основное преимущество — блокировки на уровне строки. Тоесть при большом количестве одновременных UPDATE,INSERT не получим столько блокировок таблиц, как на myisam.
Но InnoDB нельзя срезать бинарно. И это для меня был самый большой минус. Так как таблицы были огромными и гигантские дампы не доставляли радости. Особенно, если при разворачивании дампа закрадывалась ошибка в файле…
Потому, не стоит рекомендовать всем использовать InnoDB. Надо использовать именно тот storage engine, который подходит твоему проекту, твоей структуре БД и твоим запросам к БД.
UFO just landed and posted this here
Да, это как раз и есть предыдущая версия «тюнинга по Сысоеву» Интересно посмотреть, но часть информации уже не актуальна.
Как же интересно кто те трое, что поставили этому топику минус. Черт подери. и как обычно без каких-либо объяснений.
как по мне то mysqltuner намного лучше приведенных примеров.
Мне не понравился пункт про кеширование на nginx и на клиенте. Имхо кешировать данные в паммяти должно веб-приложение, та как оно точно знает что и когда изменилось, а что не будет меняться, и уж точно не nginx.
Кеширование на клиенте — можно конечно и так, тупо «в лоб» прописать всем expires, но только в том случае если вы эти файлы не планируете обновлять.
Кеширование на клиенте — можно конечно и так, тупо «в лоб» прописать всем expires, но только в том случае если вы эти файлы не планируете обновлять.
Кеширование на клиенте — очень хорошая экономия трафика и pps.
ПС. Обновляем файл — меняем название.
ПС. Обновляем файл — меняем название.
> Обновляем файл — меняем название.
Руками???? Всюду, где встречается ссылка на него??
Я не спорю с важностью кеширования на клиенте, просто поддержка должна быть реализована на уровне приложения или фреймворка на котором оно строится, а то, что тут предложено — муть.
Руками???? Всюду, где встречается ссылка на него??
Я не спорю с важностью кеширования на клиенте, просто поддержка должна быть реализована на уровне приложения или фреймворка на котором оно строится, а то, что тут предложено — муть.
да ну зачем же руками… формируем все ссылки на статику например вот так domain.com/hash.23442334/main.css, где hash.23442334/ — хеш строка, генерируемая по заранее нам известному паттерну, из урла эту строку убираем рерайтом, так чтоб nginx искал файл domain.com/main.css, при изменении main.css система кеширования должна сообщить генератору документов что теперь пора подставлять новую хеш строку
Вместо встроенного InnoDB в MySQL можно попробовать InnoDB Plugin. Судя по тестам, он дает хорошую производительность по сравнению со встроенным InnoDB.
для постгресса посоветовал бы pgAdmin III.
плюс посоветовал бы отключить автовакуум если большая база и делать аналайз отдельным таблицам.
и раз в неделю делать фул аналайз с перестройкой индексов
плюс посоветовал бы отключить автовакуум если большая база и делать аналайз отдельным таблицам.
и раз в неделю делать фул аналайз с перестройкой индексов
>LVM снапшоты — это тормоз.
В начале статьи про фрю да про фрю, а потом внезапно LVM. С чего бы это?
БД на линуксе? Почему?
>Поскольку самым лучшим инструментом, на мой взгляд, являются клоны в ZFS.
Как насчет dump/restore из FreeBSD?
>Делаются мгновенно
Всмысле, быстрее физической скорости работы накопителей, с/на которые копируются данные?
Интересно.
В начале статьи про фрю да про фрю, а потом внезапно LVM. С чего бы это?
БД на линуксе? Почему?
>Поскольку самым лучшим инструментом, на мой взгляд, являются клоны в ZFS.
Как насчет dump/restore из FreeBSD?
>Делаются мгновенно
Всмысле, быстрее физической скорости работы накопителей, с/на которые копируются данные?
Интересно.
>В начале статьи про фрю да про фрю, а потом внезапно LVM. С чего бы это?
>БД на линуксе? Почему?
Последний раздел «Приложение. Мелочи.» платформонезависимый.
Вообще, много кто делает DB на Linux, ибо до 7ки с мултитредингом у FreeBSD было совсем всё плохо.
>Как насчет dump/restore из FreeBSD?
тестов я не делал, но судя по тому, что оно юзает снапшоты ufs (
>Всмысле, быстрее физической скорости работы накопителей,
>с/на которые копируются данные?
ZFS не перезаписывает данные, поэтому снапшот не является «копией» данных, просто те данные которые уже имеются на винчестере не перезаписываются новыми.
Соответственно создание снапшота, это по сути команда «не перезаписывать вот эту FS, все изменённые блоки писать на свободное место», которая выполняется практически мгновенно.
>БД на линуксе? Почему?
Последний раздел «Приложение. Мелочи.» платформонезависимый.
Вообще, много кто делает DB на Linux, ибо до 7ки с мултитредингом у FreeBSD было совсем всё плохо.
>Как насчет dump/restore из FreeBSD?
тестов я не делал, но судя по тому, что оно юзает снапшоты ufs (
dump -L) и соответственно использует copy-on-write, производительность должна падать до уровеня LVM снапшотов.>Всмысле, быстрее физической скорости работы накопителей,
>с/на которые копируются данные?
ZFS не перезаписывает данные, поэтому снапшот не является «копией» данных, просто те данные которые уже имеются на винчестере не перезаписываются новыми.
Соответственно создание снапшота, это по сути команда «не перезаписывать вот эту FS, все изменённые блоки писать на свободное место», которая выполняется практически мгновенно.
>Вообще, много кто делает DB на Linux, ибо до 7ки с мултитредингом у FreeBSD было совсем всё плохо.
Многие делают, но судя по статье у вас никаких проблем с квалификацией администраторов FreeBSD нет. Почему бы не использовать её для серверов БД, тем более для PostgreSQL?
>ZFS не перезаписывает данные, поэтому снапшот не является «копией» данных, просто те данные которые уже имеются на винчестере не перезаписываются новыми.
Спасибо за пояснение. Кстати, недавно тут была новость про готовность ZFS в FreeBSD к продакшну, снапшоты там уже реализованы. Вы их имели в виду или снапшоты ZFS на солярисе?
Многие делают, но судя по статье у вас никаких проблем с квалификацией администраторов FreeBSD нет. Почему бы не использовать её для серверов БД, тем более для PostgreSQL?
>ZFS не перезаписывает данные, поэтому снапшот не является «копией» данных, просто те данные которые уже имеются на винчестере не перезаписываются новыми.
Спасибо за пояснение. Кстати, недавно тут была новость про готовность ZFS в FreeBSD к продакшну, снапшоты там уже реализованы. Вы их имели в виду или снапшоты ZFS на солярисе?
UFO just landed and posted this here
Вы просто монстр…
Если пулер соединений у вас не установлен, то на каждое соединение с базой у вас запускается отдельный процесс
Некорректная формулировка. С пулером или без, число процессов равно числу клиентов. Пулер же просто держит пул открытых соединений, убирая оверхед создания нового процесса при подключении клиента (и прибивания процесса при отключении), так что, например, после кратковременной серьезной нагрузки у вас останется висеть довольно долго куча ничего не делающих процессов.
В общем, да, пулер безусловно необходим.
Класс. Хорошая статья — это когда тонны пунктуационных ошибок даже не замечаешь. Особое спасибо за ссылки.
Очень профессионально, в мемориз однозначно.
Полезная статья — зачет! :-) Пригодится как краткий справочник и набор связных ссылок.
На мой взгляд применительно к сетевушкам не стоит всем сразу поллинг рекомендовать — пусть сначала хотя бы загрузку по прерываниям посмотрят. А то уже который раз везде вижу, что народ считает поллинг каким-то универсальным способом решения всех проблем. ;-) А на тех же em он вообще сильно вреден. И nfe, кстати, очень неплохие сетевушки — нагрузку держат адекватно, производительность хорошая и с прерываниями как раз не шалят… Еще можно предостеречь от msk — их сейчас много (D-Link DGE-560T), стоят дешево и есть большой соблазн купить и поставить. И ведь даже работать будут под небольшой нагрузкой… А потом начнут тупо выключаться. Уже почти год мой bug висит, подтверждения на него от других людей есть, а хоть бы хны… И еще напишите, что далеко не во всех em есть все ништяки. pci-e Интеловские карточки действительно большей частью стоят своих денег. :-)
Насчет ZFS — нужно было хотя бы упомянуть в разделе про файловые системы. На amd64 оно production ready уже очень давно и даже ядро тюнить не надо (у меня несколькотерабайтный файловый сервер несколько лет работает нормально). В восьмерке довели до того, что на i386 работает из коробки, но я бы и на 7.2 amd64 сейчас собирал не боясь… Слишком уж там raidz вкусный. :-)
И про InnoDB в комментах уже говорили — если не нужны транзакции и атомарность (а они нужны далеко не везде, особенно если сам сидит и проектируешь базу), то MyISAM вполне себе в деле. :-) Ну и что, что табличка может побиться? Се ля ви, так сказать (тем более, это не такое уж частое являение). Зато если она КОНКРЕТНО побилась, то пусть и не быстро, зато восстановится она без особого напряга безо всяких бэкапов. Кроме того, не забывайте о скорости и памяти — таки на VDS, особенно на младших тарифах, это вполне себе играет определенную роль… Короче, InnoDB не есть панацея для всех случаев. Я бы лучше порекомендовал начинать проект как раз на MyISAM, а когда проект вырастет, уйдет с VDS на свой сервер да и о репликации базы начнете думать — тогда да, уже InnoDB. А ежели в проекте табличка еще меньше гига, а ее из-за MyISAM уже блокировки замучали, то, извините, это не в MyISAM проблемы, а в том, кто базу и ее приложения проектировал. :-)
На мой взгляд применительно к сетевушкам не стоит всем сразу поллинг рекомендовать — пусть сначала хотя бы загрузку по прерываниям посмотрят. А то уже который раз везде вижу, что народ считает поллинг каким-то универсальным способом решения всех проблем. ;-) А на тех же em он вообще сильно вреден. И nfe, кстати, очень неплохие сетевушки — нагрузку держат адекватно, производительность хорошая и с прерываниями как раз не шалят… Еще можно предостеречь от msk — их сейчас много (D-Link DGE-560T), стоят дешево и есть большой соблазн купить и поставить. И ведь даже работать будут под небольшой нагрузкой… А потом начнут тупо выключаться. Уже почти год мой bug висит, подтверждения на него от других людей есть, а хоть бы хны… И еще напишите, что далеко не во всех em есть все ништяки. pci-e Интеловские карточки действительно большей частью стоят своих денег. :-)
Насчет ZFS — нужно было хотя бы упомянуть в разделе про файловые системы. На amd64 оно production ready уже очень давно и даже ядро тюнить не надо (у меня несколькотерабайтный файловый сервер несколько лет работает нормально). В восьмерке довели до того, что на i386 работает из коробки, но я бы и на 7.2 amd64 сейчас собирал не боясь… Слишком уж там raidz вкусный. :-)
И про InnoDB в комментах уже говорили — если не нужны транзакции и атомарность (а они нужны далеко не везде, особенно если сам сидит и проектируешь базу), то MyISAM вполне себе в деле. :-) Ну и что, что табличка может побиться? Се ля ви, так сказать (тем более, это не такое уж частое являение). Зато если она КОНКРЕТНО побилась, то пусть и не быстро, зато восстановится она без особого напряга безо всяких бэкапов. Кроме того, не забывайте о скорости и памяти — таки на VDS, особенно на младших тарифах, это вполне себе играет определенную роль… Короче, InnoDB не есть панацея для всех случаев. Я бы лучше порекомендовал начинать проект как раз на MyISAM, а когда проект вырастет, уйдет с VDS на свой сервер да и о репликации базы начнете думать — тогда да, уже InnoDB. А ежели в проекте табличка еще меньше гига, а ее из-за MyISAM уже блокировки замучали, то, извините, это не в MyISAM проблемы, а в том, кто базу и ее приложения проектировал. :-)
Спасибо за статью!
По поводу багов в MySQL 5.1, не в обиду самому мускулю, сам им пользуюсь все время. Просто так сложилось, что сам вчера переходил с 4ки на 5.1. Так вот серак 5.1 валится если в названиях полей использовать несколько тире. Например «bred-------»
Поля подобного рода у меня использовались для визуальной группировки полей в таблице во время разработки проекта. нигде они ессесно не используются в проекте, поэтому проект работает, а мускуль падает при обычной процедуре дампа. Понадобилось 30 минут что бы выкупить :)
Поля подобного рода у меня использовались для визуальной группировки полей в таблице во время разработки проекта. нигде они ессесно не используются в проекте, поэтому проект работает, а мускуль падает при обычной процедуре дампа. Понадобилось 30 минут что бы выкупить :)
ну так в мануал заглядывать перед такими переездами стоит
dev.mysql.com/doc/refman/5.1/en/ansi-diff-comments.html
dev.mysql.com/doc/refman/5.1/en/ansi-diff-comments.html
Немного не по теме — а как насчет CentOS? Одни админы рекомендутю FreeBSD, другие CentOS. Непонятно. :)
Спасибо, много интерестных вещей.
Великолепный материал, то что нужно, в закладки, спасибо .)
«TCP Segent Offloading» — segMent
Припозднился я конечно, но не отдать дань уважения не смог. Для обладателей VDS с амбициями, этот пост — боевой листок.
Спасибо!
Спасибо!
Sign up to leave a comment.
Сервер на стероидах: FreeBSD, nginx, MySQL, PostgreSQL, PHP и многое другое