Разработчик
40,0
рейтинг
9 декабря 2010 в 09:01

Администрирование → Ускоряем раздачу фоток


С проблемой медленной отдачи статического контента рано или поздно сталкивается каждый сисадмин.

Проявляется это приблизительно так: иногда 3Kb картинка грузится так, как будто бы она весит 3Mb, на ровном месте начинают «залипать» (отдаваться очень медленно) css-ы и JavaScript-ы. Вы нажимаете ctrl + reload — и уже, вроде, проблемы нет, потом спустя всего несколько минут все повторяется опять.

Не всегда истинная причина «тормозов» очевидна и мы косо поглядываем то на nginx, то на хостера, то на «забитый» канал, то на «тормозной» или «глючный» браузер :)

На самом деле проблема в несовершенстве современного винчестера, который до сих пор не расстался с механическими подсистемами вращения шпинделя и позиционирования головок.

В этой статье я предложу Вам свое решение этой проблемы, основанное на практическом опыте использования SSD дисков совместно с web-сервером nginx.


Как понять, что хард тормозит?


В Linux проблемы со скоростью дисковой системы напрямую связаны с параметром iowait (процент простоя CPU в ожидании операций ввода/вывода). Для того, чтоб мониторить этот параметр есть несколько комманд: mpstat, iostat, sar. Я обычно запускаю iostat 5 (замеры будут производиться каждые 5 сек.)
Я спокоен за сервер, у которого средний показатель iowait до 0.5%. Скорее всего на Вашем сервере «раздачи» этот параметр будет выше. Есть смысл не откладывать оптимизацию, если iowait > 10% Ваша система тратит очень много времени на перемещение головок по винчестеру вместо чтения информации, это может приводить к «торможению» и других процессов на сервере.

Как быть с большим iowait?


Очевидно, что если уменьшить количество дисковых операций ввода/вывода, винчестеру стант легче и iowait упадет.
Вот несколько рекомендаций:
  • Отключите access_log
  • Отключите обновление даты последнего доступа к файлу и директории, также позвольте системе кешировать операции записи на диск. Для этого монтируем файловую систему со следующими опциями: async,noatime,barrier=0. ('barrier=0' неоправданный риск, если на этом же разделе находится база данных)
  • Можно увеличить таймаут между сбросом «грязных» буферов vm.dirty_writeback_centisecs в /etc/sysctl.conf. У меня установлено vm.dirty_writeback_centisecs = 15000
  • Вы случайно не забыли про директиву expires max?
  • Не лишним будет включить кеширование дескрипторов файлов.
  • Приминение клиентской оптимизации: css-спрайты, все css — в один файл, все js — в один файл

Это немного поможет и даст время продержаться до апгрейда. Если проект растет, iowait о себе скоро напомнит. :)

Апгрейдим железо


  • Доустанавливаем RAM
    Пожалуй, начать можно с оперативной памяти. Linux задействует всю «свободную» оперативную память и разместит там дисковый кеш.
  • Старый провереный RAID-массив
    Можно собрать програмный или аппаратный RAID из нескольких HDD. В некоторых случаях есть смысл увеличивать количество винчестеров, но при этом не собирать их в RAID (например раздача iso-образов диска, больших видео-файлов, ...)
  • Solid-state drive: попробуем что-то новенькое
    Ну и самый, на мой взгляд, дешевый вариант апгрейда — доустановить в систему один или несколько SSD дисков. Cегодня, как Вы уже догадались, речь пойдет именно об этом способе ускорения.

Абсолютно не повлияет на скорость раздачи апгрейд CPU, потому что «тормозит» не он! :)

Почему SSD


Полтора года назад, когда я писал статью «Тюнинг nginx», одним из предложенных мной вариантов ускорения nginx было использование SSD винчестера. Хабрасообщество сдержано проявляло интерес к этой технологии, была информация о возможном торможении со временем SSD и опасение за малое количество циклов перезаписи.
Совсем скоро после публикации той статьи в нашей компании появился Kingston SNE125-S2/64GB на базе SSD Intel x25e который по сегодняшний день используется на одном из самых нагруженых серверов «раздачи».

После года экспериментов проявилось ряд недостатков, о которых мне хотелось бы рассказать:
  • Рекламный трюк: если в рекламе SSD написано что Максимальная скорость чтения, 250 Мб/с, то это означает что средняя скорость чтения будет равняться ~ 75% (~ 190Мб/с) от заявленной максимальной. Уменя так было с MLC и SLC, дорогими и дешёвыми
  • Чем больше объем одного SSD, тем выше стомость 1Мб на этом диске
  • Большинство файловых систем не адаптированы к использованию на SSD и могут создавать неравномерную нагрузку по записи на диск
  • Только самые современные (и соответственно самые дорогие) RAID-конроллеры адаптированы к подключению к ним SSD
  • SSD все еще остается дорогой технологией

Почему я использую SSD:
  • Реклама не врет — seek-to-seek действительно стремится к 0. Что позволяет существенно уменьшить iowait при паралельной «раздаче» большого количества файлов.
  • Да, действительно, количество циклов перезаписи ограничено, но мы об этом знаем и можем минимизировать количество перезаписываемой информации с помощью методики, описаной чуть ниже
  • Сейчас уже доступны диски, использующие технология SLC (Single-Level Cell) с «умным» конроллером, количество циклов перезаписи у которых на порядок выше обычных MLC SSD
  • Современные файловые системы (например btrfs) уже умеют правильно работать с SSD
  • Как правило, кеширующий сервер требует небольшое количество места под кеш (у нас это 100-200G), что может уместиться на 1 SSD. Получается, что это существенно дешевле решения на базе аппаратного RAID-масива c несколькими SAS дисками


Настраиваем SSD кеш


Выбор файловой системы
Вначале эксперимента на Kingston SNE125-S2/64GB была установлена ext4. В интернете вы найдете множество рекомендаций как «отрубить» журналирование, даты последнего доступа к файлам, и т.д. Все работало идеально и длительное время. Самое главное, что не устраивало — при большом количестве мелких фотграфий 1-5K на 64G SSD помещалось меньше половины — ~20G. Я начал подозревать, что мой SSD используется не рационально.

Проапгрейдил ядро до 2.6.35 и решил попробовать (пока еще экспериментальную) btrfs, там есть возможность при монтировании указать, что монтируется ssd. Диск можно не разбивать на разделы, как это принято, а форматировать целиком.

Пример:
mkfs.btrfs /dev/sdb

При монтировании можно отключить множество фич, которые нам не понадобятся и включить компрессию файлов и метаданных. (На самом деле jpeg-и сжиматься не будут, btrfs умная, сжатию будут подвергаться только метаданные). Вот как выглядят моя строка монтирования в fstab (все одной строкой):

UUID=7db90cb2-8a57-42e3-86bc-013cc0bcb30e /var/www/ssd btrfs device=/dev/sdb,device=/dev/sdc,device=/dev/sdd,noatime,ssd,nobarrier,compress,nodatacow,nodatasum,noacl,notreelog 1 2

Узнать UUID отформатированного диска можно командой
blkid /dev/sdb


В итоге на диск «влезло» более 41G (в 2 раза больше, чем на ext4). При этом скорость раздачи не пострадала (т.к. iowait не увеличился).

Собираем RAID из SSD
Наступил такой момент, когда 64G SSD стало мало, захотелось собрать несколько SSD в один большой раздел и при этом было желание использовать не только дорогие SLC, но и обычные MLC SSD. Тут надо вставить немного теории:

Btrfs сохраняет на диске 3 типа данных: данные о самой файловой системой, адреса блоков метаданных (на диске ведется всегда 2 копии метаданных) и, собственно, сами данные (содержание файлов). Экспериментальным путем я установил, что в нашей структуре директорий «сжатые» метаданные занимают ~30% от всех данных раздела. Метаданные — это самый интенсивно изменяемый блок, т.к. любое добавление файла, перенос файла, изминение прав доступа влечет за собой перезапись блока метаданных. Область где хранятся просто данные перезаписывается реже. Вот мы и подошли к самой интересной возможности btrfs: это создавать софтовые RAID-масыви и указывать явным образом, на каких дисках сохранять данные на каких метаданные.

Пример:
mkfs.btrfs -m single /dev/sdc -d raid0 /dev/sdb /dev/sdd

в результате метаданные будут создаваться на /dev/sdc а данные на /dev/sdb и /dev/sdd, которые будут собраны в stripped raid. Мало того, к существующей системе можно подключать еще диски, выполнять балансировку данных и т.д.

Чтоб узнать UUID btrfs RAID-а запустите:
btrfs device scan

Внимание: особенность работы с btrfs-райдом: перед каждым монтироваем RAID-масива и после загрузки модуля btrfs необходимо запускать комманду: btrfs device scan. Для автоматического монтирования через fstab можно обойтись без 'btrfs device scan', добавив опции device в строку монтирования. Пример:
/dev/sdb     /mnt    btrfs    device=/dev/sdb,device=/dev/sdc,device=/dev/sdd,device=/dev/sde


Кеширование на nginx без proxy_cache


Я предполагаю, что у вас есть storage-сервер, на котором находится весь контент, на нем много места и обычные «неповоротливые» SATA винчестеры, которые не в состоянии держать большую нагрузку совместного доступа.
Между storage-сервером и пользователями сайта есть сервер «раздачи», задача которого снять нагрузку с storage-сервера и обеспечить бесперебойную «раздачу» статики любому количеству клиентов.

Установим на сервер раздачи один или несколько SSD с btrfs на борту. Сюда прямо напрашивается конфигурация nginx на базе proxy_cache. Но у нее есть несколько минусов для нашей сисемы:
  • proxy_cache при каждом перезапуске nginx начинает постепенно сканировать все содержимое кеша. Для нескольких сотен тысяч это вполне допустимо, но если в кеш мы ложим большое количество файлов то такое поведения nginx — неоправданный расход дисковых операций
  • для proxy_cache не существует родной системы «чистки» кеша, а сторонние модули позволяют чистить кеш только по одному файлу
  • есть небольшой overhead по расходу CPU, т.к. при каждой отдаче выполняется MD5-хеширование над строкой, заданной в директиве proxy_cache_key
  • Но самое важное для тас то, что proxy_cache не заботится о том чтоб кеш обновлялся с наименьшим количеством циклов перезаписи информации. Если файл «вылетает» из кеша, то он удаляется и, если запрашивается повторно, то повторно записывается в кеш

Мы возьмем на оворужение другой подход к кешированию. Идея промелькнула на одной из конференций по hiload. Создаем в разделе кеша 2 директории cache0 и cache1. Все файлы при проксировании сохраняем в cache0 (с помощью proxy_store). nginx заставляем проверять наличие файла (и отдавать файл клиенту) сначала в cache0 потом в cache1 и если файл не найден, идем на storage сервер за файлом, затем сохраняем его в cache0.
Через некоторое время (неделя/месяц/квартал) удаляем cache1, переименовываем cache0 в cache1 и создаем пустой cache0. Анализируем логи доступа к секции cache1 и те файлы, которые запрашиваються из этой секции перелинковываем в cache0.

Этот метод позволяет существенно сократить операции записи на SSD, т.к. перелинковка файла — это все же меньше, чем полная перезапись файла. Кроме того можно собрать рейд из нескольких SSD, 1 из которых будет SLC для метаданных и MLC SSD для обычных данных. (На нашей системе метаданные занимают приблизительно 30% от общего объема данных). При перелинковке будут перезаписаны только метаданные!

Пример конфигурации nginx

log_format cache0  '$request';
# ...
server {  
  expires max;

  location / {
    root /var/www/ssd/cache0/ ;
    try_files $uri @cache1;
    access_log off;
  }

  location @cache1 {
    root /var/www/ssd/cache1;
    try_files $uri @storage;
    access_log /var/www/log_nginx/img_access.log cache0;
  }

  location @storage {
    proxy_pass http://10.1.1.1:8080/$request_uri;
    proxy_store on;
    proxy_store_access user:rw  group:rw  all:r;
    proxy_temp_path /var/www/img_temp/; # обязательно не на SSD!
    root /var/www/ssd/cache0/;
    access_log off;
  }
# ...


Скрипты для ротации cache0 и cache1
Я написал на bash несколько скриптов, которые помогут вам реализовать ранее описанную схему ротации. Если размер вашего кеша измеряется сотнями гигабайт а количество контента в кеше миллионами, то скрипт ria_ssd_cache_mover.sh сразу после ротации желательно запускать несколько раз подряд следующей командой:

for i in `seq 1 10`; do ria_ssd_cache_mover.sh; done;
Время, за которое выполнится эта команда установите експериментаольно. У меня она работала почти сутки. На сл. сутки устанавливаем запуск ria_ssd_cache_mover.sh на cron-е каждый час.

Защита от DOS-а storage server-а
Если storage server хиловат, и есть недоброжелатели, жаждущие задосить Вашу систему, можно совместно с описанным решением применить модуль secure_link

Полезные ссылки




UPD1: Все же советую использовать ядро >= 2.6.37 и старше, т.к. у меня на 2.6.35 недавно произошел большой креш кеша из-за переполнения места на SSD с метаданными. В результате пришлость форматировать несколько SSD и заново собирать btrfs-рейд. :(

Олег Черний @apelsyn
карма
167,1
рейтинг 40,0
Разработчик
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (69)

  • +4
    с параметром iowait (процент простоя CPU в ожидании дисковых операций ввода/вывода)
    Туда же относится ожидание ответа от сетевой подсистемы ввода-вывода.
    А в целом за статью +, поделились полезным опытом.
  • 0
    Спасибо, поправил.
  • 0
    > Совсем скоро после публикации той статьи в нашей компании появился Kingston SNE125-S2/64GB на базе SSD Intel x25m

    Вы ничего не путаете? SNE сделан на базе x25e.
    • 0
      Спасибо, что подсказали неточность. Действительно x25e.
  • +1
    А какие у вас smart параметры после года использования?
    Вот эти:
    Код E1 – Host Writes
    Код E9 – Media Wearout Indicator
    • 0
      ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
        3 Spin_Up_Time            0x0000   100   000   000    Old_age   Offline      -       0
        4 Start_Stop_Count        0x0000   100   000   000    Old_age   Offline      -       0
        5 Reallocated_Sector_Ct   0x0002   100   100   000    Old_age   Always       -       0
        9 Power_On_Hours          0x0002   100   100   000    Old_age   Always       -       4732
       12 Power_Cycle_Count       0x0002   100   100   000    Old_age   Always       -       73
      192 Unsafe_Shutdown_Count   0x0002   100   100   000    Old_age   Always       -       55
      232 Available_Reservd_Space 0x0003   100   100   010    Pre-fail  Always       -       0
      233 Media_Wearout_Indicator 0x0002   099   099   000    Old_age   Always       -       0
      225 Host_Writes_32MiB       0x0000   200   200   000    Old_age   Offline      -       21659
      226 Intel_Internal          0x0002   255   000   000    Old_age   Always       -       0
      227 Intel_Internal          0x0002   000   000   000    Old_age   Always       -       0
      228 Intel_Internal          0x0002   000   000   000    Old_age   Always       -       0
      
      SMART Error Log Version: 1
      No Errors Logged
      

  • 0
    Не сочтите за занудство, но тут: «В Linux проблемы со скоростью дисковой системой напрямую связаны» видимо «системы». А в целом за статью спасибо. Добавил в закладки. 8)
    • 0
      Спасибо, поправил
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    может конечно скажу глупость — но вы не думаете, что придётся очень часто менять такие ssd диски — ведь у них число циклов чтение-запись весьма небольшое. А использовать их в качестве кеша, к которому как раз и пойдёт основной поток запросов на чтение мягко говоря глупо.

    Спасибо за внимание.
    • 0
      написано же — прошел год
      • 0
        да но ведь не написано сколько за это время убилось ssd… или я невнимательно читал?
        • +3
          При експерименте ни один из SSD не пострадал :)
        • 0
          Цитата:
          I once ran a multi week attempt to burn out various vendors’ SSDs. I ran them flat out 100% random writes for about a month. Fusion IOs at something like 30k IOPs per drive, STECs / Intels around 7k. Never was able to get any of them to fail.
          The Fusion IO did as many writes that month as a single SAS drive could do in over a decade.

          PS. «decade» это «десять лет» в английском.
          • 0
            спасибо… я понял
            видимо остался у меня стереотип
        • 0
          Да у него всего 600 гб записей за год. А лимит когда стоит начинать думать о износе в районе 50 тб.
    • +3
      Для преимущественно _отдачи_ конечное число циклов _записи_ не критично.
    • +3
      ограничено кол-во записей. а чтение — не ограничено вообще. даже когда ссд уже совсем не пишется — он будет читаться. пока там что-то не сгорит ))
  • 0
    Лично у меня iowait иногда доходит до 70%
    точнее доходил.
    Как ПРАВИЛЬНО победить задержки раздачи файлов для обычного сайта.
    решение номер 1 —
    Когда у вас спросят — сколько памяти ставить в новый сервер 2 или 4 гига — скажите «ставьте 16»
    Лично у меня вся статика занимает ну максимум гигов 6. И я уверен — она всегда будет браться из кеша.

    решение номер 2 —
    NCQ, AIO и другие механизмы которые позволяют отдать больше файлов большему количеству клиентов с большими задержками.
    Да именно что с большими — если системе надо будет подождать пару секунд чтобы жесткий более непрерывно выполнил свою работу — это позволит обработать СИЛЬНО большее количество клиентов ценой появления маленьких задержек. Ну и чем меньше клиентов тем меньше задержек

    если же у вас файлопомойка и у вас много много файлов — вас окончательно не спасет никакое решение. Потому что решение которое вас спасет — себя просто не окупит

    ПС: да, я абсолютно уверен что массив из обычных дисков + куча рама более эффективен чем ssd за те же деньги.
    • +1
      В статье написано, что размер кеша — 200G. Это примерно $1000 как ssd и раз в 10 дороже в виде ram.
      • +1
        Окей, вопрос номер два — что такое cache-hit, cache-miss и мифический «плоский»(равномерно-рандомный) вариант доступа к данным. Когда запрашиваются вроде как все, но вроде как один-два раза в день.
        Так что путаем размер кеша и размер активно используемого кеша.

        Когда я работал в викимапии система рендера тайлов сильно упиралась именно в «плоский» вариант доступа к данным. Иногда было быстрее не брать данные из кеша, а сгенерить их на месте чем просто поискать их в кеше и вернуть.
        Но там кем был не 200G и даже не 2000G.
        • 0
          Мой 1 сервер раздачи отдает в среднем 100 000 — 150 000 фоток в минуту в штатном режиме и приблизительно 200 000 фоток в минуту (в пиковые часы). В вашем случае мы переносим нагрузку из кеша на процессоры. Для меня процессорное время дороже чес SSD кеш.
    • 0
      Вы наверное не обратили внимание, что первое что я бы апгрейдил — это имеено RAM, но не во всякую материнку можно поставить более 16G кеша. Кроме того если у Вас все фотки помещаются в 6G и Ваш сайт растет то это означает что когда нибудь Ваши 16G тоже Вас не спасут :)
  • 0
    > nodatacow

    Почему?
    • 0
      При включенном механизме copy-on-write появляются дополнительные издержки в виде дискового пространства на SSD (На диск 64G при включенном copy-on-write и записи большого количество фоток размером 1-5K, влезало на ~8G меньше чем с nodatacow).
      • 0
        Справедливости ради надо сказать что я отключил не только copy-on-write пареметры nodatasum,noacl,notreelog тоже повлияли на вместительность SSD винта
  • 0
    Вот мы и подошли к самой интересной возможности btrfs: это создавать софтовые RAID-масыви и указывать явным образом, на каких дисках сохранять данные на каких метаданные
    Что произойдет при «вылетании» диска с метаданными? Данные будут доступны при обычном монтировании диска?
    • 0
      На диске с метаданными хранится 2 копии метаданных. Если будут повреждены сразу две копии одновременно (что маловероятно для SSD) то надо запускать чекер и быть готовым к тому что часть кеша может не ввостановиться.
  • 0
    Пришла подсказка из зала, цитирую:
    "
    я сам писал статьи на эти темы еще лет 5-7 назад на computing.net когда все это начиналось! Но есть подводные камни которые отсутствуют в этой статье! SSD пока что не годится для высоконагруженных проектов!
    Есть намного лучшее решение (которое было на рыеке с 2001года, а сейчас ушло далеко вперед! Я сам собирал серваки с Itanium 2 на основе этих накопителей!) ACARD ANS-9010 5.25" SATAx2 to DDR2 Ram Disk Drive
    "
    Для тех кому лень лезть по ссылке:
    ACARD RAM Disk Box acts like a regular SATA hard drive at 400MB/s data transfer rate. By utilizing conventional DDR2 memory modules, ACARD ANS-9010 is outfitted with 8 240-pin DDR2 DIMM module slots and support up to 64GB memory. Most of all, the major issue of data lost after powering down is solved by RAM Disk’s backup battery plus CF slot for data backup.

    Memory Interface
    Memory Capacity: 64GB
    Memory Slot: 8 240-pin DDR2 DIMM module slots
    Memory Type: ECC/Non-ECC DDR2 400/533/667/800**

    Цена правда: $327.00
    • 0
      > SSD пока что не годится для высоконагруженных проектов!

      Реальность не подтверждает. SSD применяется очень широко уже сейчас, и темпы роста очень высокие.
      • 0
        Про уровень подсказки из зала становится понятно уже по одному только наличию восклицательного знака в конце каждого предложения. ;)
  • 0
    «Сейчас уже доступны диски, использующие технология SLC (Single-Level Cell) с «умным» конроллером.»

    Вообщето изначально были доступны только SLC диски, MLC появились позже.

    кроме того 100000 циклов перезаписи котороые приписываются SLC ячейкам сильно завышены.
    • +1
      Ваши сведения устарели. В области SSD все меняется к лучшему очень быстро. Сегодня ситуация с количеством циклов у современных SLC SSD в реальной жизни практически равна такой у HDD.

      blog.aboutnetapp.ru/archives/669
      • –2
        вы путаете рекламируемое время жизни (MTBF) ssd по сравнению с hdd с количеством перезаписи одной ячейки. Интел например в последнем интеловском написано «1 петабайт рандомной записи за время жизни винта» для 32Г модели. если у вас полвинта занято и остальное перезаписывается регулярно это будет уже только 512 терабайт за время жизни и тд. При неслучайной записи до петабайта будет ой как далеко.

        но даже петабайт при скорости 170 мегабайт в сек запишутся за 73 дня, что гораздо меньше 2 миллионов часов MTFB
        • +2
          Вы правда считаете, что я не различаю разницу между «MTBF» и реальным положением дел? ;)

          Цитаты по ссылке, приведенной выше, это мнения админов-практиков, эксплуатирующих системы с деcятками и сотнями SSD.
          • 0
            все зависит от типа нагрузок, у меня например четыре интеловских SSD купленых для кеша полгода назад (нужна быстрая запись и паралельное чтение) уже показывают по паре десятков реаллоков, причем реально за эти полгода винты работали месяца три. Соответственно если мы пустим их из тестовой нагрузки в полную выйдут из строя за год (при этом они конечно себя окупят, но надо расчитывать время на даунтайм что тоже расходы)

            С другой стороны у нас есть 4 15K SAS винта с чуть меньшей (процентов на 15) загрузкой на запись, но им уже по три года и до сих пор ни одного реаллока.

            • 0
              Даже 15к SASы не показывают такого времени доступа как SLC SSD.
              В этом их прелесть.

              Пока SAS только seek-ает SSD уже отдал данные.
              • 0
                привет кэп :)

                P.S. в некоторых диапазонах размеров блоков на запись эти SAS таки немного быстрее, но только в очень узком диапазоне
    • 0
      «SLC с «умным» конроллером» от Intel появились в 2008 году. Нащет 100000 циклов не проверял, возможно єто маркетинговый ход.
  • +7
    Когда картинок очень много столкнулись с большим увеличением iowait с некоторой периодичностью. Как оказалось, следует отключить updatedb.
    • 0
      Я про это совсем забыл. Действительно, можно либо отрубить updatedb либо /etc/updatedb.conf прописать исключение для директории с кешом.
    • 0
      А можно чуть поподорбнее, что это такое?
      • +1
        Коротко говоря — индексатор файлов.
        При ~3 млн. картинок расположенных в структуре каталогов 256х256 iowait был около 50-60%.
  • 0
    А как вы смотрите на размещение СУБД на SSD?
    По моим наблюдениям она у нас даёт основную нагрузку на io
    • 0
      Для базы данных я бы все же использовал RAID-массив из SAS-дисков. База данных породит намного больше трафика на запись.
      • 0
        Почему-то мне кажется, что современные SSD типа OCZ Vertex 2 очень умные и «размазывают» циклы записи по всем ячейкам памяти. Т.е. мереть как мухи под записью не должны.

        И именно для СУБД применний SSD-диск кажется мне наиболее привлекательным
        • 0
          Мой знакомый собрал в RAID 4 обычных MLC SSD в аппаратный RAID на хостинговый сервак с LAMP системой. Они продержались 4 месяца и умерли практически одновременно. Это было год назад, возможно современные Vertex-ы продержались бы больше.
          Для базы данных одним из самых ускоряющих факторов является кеш RAID-контроллера на запись.
          У некотрых контроллеров Areca есть возможность в контроллер установить 4Gb кеш, вот это действительно дает уменьшене iowait.
          • 0
            Вывод из этого я могу сделать только один — нужно экспериментировать :)
            И не забывать про регулярные бекапы, конечно.
        • +1
          Тут вот еще про что не стоит забывать. Для _хранения_ SSD вообще, в принципе, не очень экономически эффективен.
          Какая часть вашей базы активно считывается и записывается в течение дня? 10%? 30%? Вряд ли сильно больше. Значит от 90 до 70% данных базы просто лежат занимая сверхдорогое пространство SSD, как они могли бы замечательно лежать на SATA за 80$, и от того, что они находятся на SSD, общая работа ничуть не ускоряется.
          Поэтому гораздо интереснее было бы использовать flash не как эмуляцию диска, а именно как память, в качестве кэша, похоже на то, что описано выше.
          При этом на SSD попадают «горячие», действительно активные данные, для которых использование Flash действительно дает максимум выигрыша.

          Сейчас именно этот вариант активно развивается, в том числе как в «больших» дисковых массивах (NetApp FlashCache), так и в отдельных кэш-контроллерах(Adaptec MaxIQ).
  • 0
    Насколько btrfs стабильнее reiserfs?
    • 0
      Не стабильней, по крайней мере ReiserFS 3.6, которая давно в ядре.
      Упаковка хвостов может помочь для экономии места при миллионах небольших файлов.
      • 0
        Я могу ошибаться, но миллионы небольших файлов это как раз то, чего стоит избегать.
        • 0
          К сожалению, это — та ситуация, которой никак не избежать.
          Например если есть хостинг изображений.

          Приведу пример. У меня есть небольшой хостинг изображений в провайдерском метронете (город и область), около 20-25 тысяч уникальных пользователей, просмотры не считаются, т.к. логи не ведем для снижения нагрузки, потому что всё железо — десктопное (проект частный, а не провайдерский).

          Так вот, у нас около миллиона файлов (всего ~170 гб). Ещё миллион — на миниатюры (~30 гб).

          // извините, могу комментировать только раз в 5 мин
      • 0
        btrfs тоже в ядре с версии 2.6.29.
        Почему я не использовал ReiserFS:
        1. Она не оптимизирована для работы с SSD и попрождает много лишних операций записи на диск (что увеличивает его износ)
        2. У нее нет возможности делать раздел на нескольких дисках, тем более указывать где хранить метаданные.
        3. Я не уверен какя система из ReiserFS и btrfs в режиме компресии экономичнее.

        Речь идет только о кеше, система на сервере раздачи находиться на обычном HDD, поэтому в случае «падения кеша» я бы мог натянуть его заново.
        • 0
          > 1. Она не оптимизирована для работы с SSD и попрождает много лишних операций записи на диск (что увеличивает его износ)
          > 2. У нее нет возможности делать раздел на нескольких дисках, тем более указывать где хранить метаданные.
          > 3. Я не уверен какя система из ReiserFS и btrfs в режиме компресии экономичнее.

          А не дешевле будет n сервера на SATA дисках с CARP или чем-то подобным?

          • 0
            Я не думаю что это будет более дешовое решение ни с точки зрения стоимости оборудования, ни с точки зрения размещения этого оборудования в датацентре.
            • 0
              Ну Dell 860 с 2 x 300 Гб дисками WD Raptor выйдет чуть дороже чем 4 SSD Intel X25-E SLC. Для SSD еще придется купить новый контроллер, который обойдется тысяч в 15-20, корпус. А потом еще эти диски года 2 при интенсивной загрузке проработают. Сможет ли даже SLC диск на частых записях выдержать хотя бы год?
    • 0
      У меня небыло ни одного падения на SSD-дисках. На btrfs я перешел не сразу, сначала все крутилось на ext4. Експерименты с btrfs я начал летом (т.е. речь идет максимум о полугодичной стабильной работе).
  • 0
    youtube решает эту проблему дешевле — рейд 10 сервера и картинки в биг тейбл, по тому что в обычной фс хранить не выгодно + кеш и распределенность из коробки
  • 0
    А не будет медленный раздел метаданных тормозить работу файловой системы. Я понимаю, что в btrfs это должно быть предусмотрено, но хотелось бы знать как именно.
    • 0
      Метаданные в btrfs «по умолчанию» хранятся на том же устройстве на котором сами данные, но принудительно вы можете их разнести по разным устройствам.
      Если вы это делаете принудительно то это означает что если метаданные ложатся на медленное устройство то они читаются медленно.
      • 0
        Ну понятно, что метаданные читаться будут медленно. А будет ли это на производительность влиять? Может же btrfs сначала быстро отдать файл, а потом в фоне обновить мету или еще как.
  • 0
    У меня на сервере где раздаеться 300гб/день мелких файлов iowait 26,76 а на другом который раздает 2тб/день 6.
  • +1
    параметр noatime включает в себя nodiratime, более того, nodiratime даже не проверяется при наличии noatime :)
    • 0
      Кашу маслом не испортиш :). Поправил.
  • 0
    кто поздскажет как посмотреть износ SSD под linux?
    • 0
      smartctl -a /dev/sda (Вместо /dev/sda имя твоего ssd-устройства)
  • +1
    MS_NOATIME implies MS_NODIRATIME.
  • 0
    >>Абсолютно не повлияет на скорость раздачи апгрейд CPU, потому что «тормозит» не он! :)

    Неверно, на скоростях порядка гигабита, процессор очень сильно играет роль. Так получалось добиваться +200Мбит с сервера просто заменив какой-то одноядерный селерон на E2160 ;)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.