Однажды появилась у нас (меня и еще одного товарища) идея воспользоваться преимуществом Гостевого доступа от Белтелекома (для тех кто не из РБ — бесплатный, безлимитный трафик для клиентов Белтелекома на все ресурсы расположенные в ЦОД Белтелекома). И решили мы открыть файлообменник.
Купили сервер (точнее собрали из того что было), установили в ЦОД, зарегистрировали домен и повесили бесплатный скрипт хостинга картинок (было давно и сейчас даже не могу найти название этого творения) который позволял качественно (относительно) хостить картинки и любые другие типы файлов. Скрипт только русифицировали, более ничего не доделывая отдали на растерзание...
Первые проблемы
Проблемы были следующими — первый опыт работы с Linux, первый опыт работы с Apache, первый опыт работы с MySQL — естественно опыт в администрировании первый. Но кое как все это работало и народ пользовался.
Дабы увеличить количество просмотров страниц нашего ресурса, и рекламы естественно, был установлен PhpBB в роли форума и места раздачи ссылок на файлы на том самом файлообменнике. Вот установка этого самого форума и стала первой серьезной проблемой, точнее ту нагрузку которую он создавал. Сервер стал (в связи с ростом посетителей) дико тормозить.
Путем недолгих изысканий был обнаружен виновник тормозов — это был MySQL, точнее то как он был настроен.
База лежала на том же диске, что и система. Никакого RAID'а небыло (точнее был но только под файлы пользователей). Настройки были те что стоят по умолчанию при установке из репозитория (система кстати была CentOS 5.2).
Долго не мучаясь был выбран шаг по вынесению форума на отдельный хостинг (обычный shared хостинг). Что и было сделано. Но радость от высокой скорости работы как форума так и хостинга файлов была недолгой. Пользователи с еще большим рвением набросились на наш сервис и хостер у которого был размещен форум сказал что платить надо больше, а точнее переходить на VPS или Выделенный сервер, что предполагало его администрирование самостоятельно и опять мы упирались в отсутствие опыта администрирования серверов MySQL.
Решение (или о чем же все таки топик)
Немного почитав о Software RAID в Linux, поизучая документацию к md было придумано следующее:
а давайте вынесем MySql базу в память (которой не хватало для Apache в такой настройке, но который был заменен на Lighttpd которому в настройке из доков столько памяти не требовалось). Ведь нагрузка то идет больше на чтение из базы чем на запись.
Но память штука такая, что если вдруг ребут — то все, базы нет.
И вот оно что — ведь в линуксе есть замечательный ramdrive. А для md — этот ramdrive ничем особо от других устройств хранения.
Действия
Стандартный размер ramdrive в 16Mb был увеличен до 2Gb (ram0).
Был создан раздел размером в те же 2Gb на диске (sda2).
И вот оно спасение: создаем RAID массив в режиме зеркала из ram0 и sda2 с чтением из ram0 (md2).
Теперь все наши данные при рестарте лежат в сохранности на жестком диске. Всего то и надо что при перезагрузке добавлять ram0 обратно к нашему массиву md2 который работает после перезагрузки только с 1 диском sda2.
Результат
Форум вернули обратно на сервер с файлами. Нагрузка осталась на уровне, не мешающем приятно работать с сервисом. За все время мы ни разу больше не уперлись в производительность MySQL (теперь были проблемы с хранилищем файлов пользователей, он (RAID5 массив) перестал справляться с возросшей нагрузкой).
Краткий итог
Как без изучения тонкостей настройки MySQL дать ему дополнительные силы — вот один из рецептов:
1. Увеличиваем размер ramdrive диска до нужного размера (добавляем параметр ramdisk_size=XXX в grub.conf) (ram0).
2. Создаем раздел такого же размера что и ramdrive (sda2).
3. Создаем RAID1 раздел из ramdrive и раздела диска (
4. Если перезагружали систему — то просто добавляем ramdrive обратно к массиву, т.к. после перезагрузки наш массив degraded (
Profit.
Данная «оптимизация» не претендует на хорошее решение, и может использоваться в небольших проектах при отсутствии навыков оптимизации MySQL. В коммандах могут быть ошибки, писал по памяти.
Купили сервер (точнее собрали из того что было), установили в ЦОД, зарегистрировали домен и повесили бесплатный скрипт хостинга картинок (было давно и сейчас даже не могу найти название этого творения) который позволял качественно (относительно) хостить картинки и любые другие типы файлов. Скрипт только русифицировали, более ничего не доделывая отдали на растерзание...
Первые проблемы
Проблемы были следующими — первый опыт работы с Linux, первый опыт работы с Apache, первый опыт работы с MySQL — естественно опыт в администрировании первый. Но кое как все это работало и народ пользовался.
Дабы увеличить количество просмотров страниц нашего ресурса, и рекламы естественно, был установлен PhpBB в роли форума и места раздачи ссылок на файлы на том самом файлообменнике. Вот установка этого самого форума и стала первой серьезной проблемой, точнее ту нагрузку которую он создавал. Сервер стал (в связи с ростом посетителей) дико тормозить.
Путем недолгих изысканий был обнаружен виновник тормозов — это был MySQL, точнее то как он был настроен.
База лежала на том же диске, что и система. Никакого RAID'а небыло (точнее был но только под файлы пользователей). Настройки были те что стоят по умолчанию при установке из репозитория (система кстати была CentOS 5.2).
Долго не мучаясь был выбран шаг по вынесению форума на отдельный хостинг (обычный shared хостинг). Что и было сделано. Но радость от высокой скорости работы как форума так и хостинга файлов была недолгой. Пользователи с еще большим рвением набросились на наш сервис и хостер у которого был размещен форум сказал что платить надо больше, а точнее переходить на VPS или Выделенный сервер, что предполагало его администрирование самостоятельно и опять мы упирались в отсутствие опыта администрирования серверов MySQL.
Решение (или о чем же все таки топик)
Немного почитав о Software RAID в Linux, поизучая документацию к md было придумано следующее:
а давайте вынесем MySql базу в память (которой не хватало для Apache в такой настройке, но который был заменен на Lighttpd которому в настройке из доков столько памяти не требовалось). Ведь нагрузка то идет больше на чтение из базы чем на запись.
Но память штука такая, что если вдруг ребут — то все, базы нет.
И вот оно что — ведь в линуксе есть замечательный ramdrive. А для md — этот ramdrive ничем особо от других устройств хранения.
Действия
Стандартный размер ramdrive в 16Mb был увеличен до 2Gb (ram0).
Был создан раздел размером в те же 2Gb на диске (sda2).
И вот оно спасение: создаем RAID массив в режиме зеркала из ram0 и sda2 с чтением из ram0 (md2).
Теперь все наши данные при рестарте лежат в сохранности на жестком диске. Всего то и надо что при перезагрузке добавлять ram0 обратно к нашему массиву md2 который работает после перезагрузки только с 1 диском sda2.
Результат
Форум вернули обратно на сервер с файлами. Нагрузка осталась на уровне, не мешающем приятно работать с сервисом. За все время мы ни разу больше не уперлись в производительность MySQL (теперь были проблемы с хранилищем файлов пользователей, он (RAID5 массив) перестал справляться с возросшей нагрузкой).
Краткий итог
Как без изучения тонкостей настройки MySQL дать ему дополнительные силы — вот один из рецептов:
1. Увеличиваем размер ramdrive диска до нужного размера (добавляем параметр ramdisk_size=XXX в grub.conf) (ram0).
2. Создаем раздел такого же размера что и ramdrive (sda2).
3. Создаем RAID1 раздел из ramdrive и раздела диска (
mdadm --create /dev/md2 --level=raid1 --raid-devices=2 /dev/sda2 --write-mostly /dev/ram0) (md2).4. Если перезагружали систему — то просто добавляем ramdrive обратно к массиву, т.к. после перезагрузки наш массив degraded (
mdadm --manage /dev/md2 --add /dev/ram0).Profit.
Данная «оптимизация» не претендует на хорошее решение, и может использоваться в небольших проектах при отсутствии навыков оптимизации MySQL. В коммандах могут быть ошибки, писал по памяти.