SSD

это действительно проблема, поэтому там где речь идет о большом количестве операций на запись используются SLC SSD диски, например на журналирование файловой системы для файловых хранилишь, но они реально дорогие.

С другой стороны на практике производительность на операции записи падает где-то в 4-е раза, что остается все так же очень высокой, например, вот результаты простого теста что мы делали на новых Интел 320, 120Гб, значения в IOPS-х:

Record length Random read Random write

4Kb 11481 13886

8Kb 7349 9953

16Kb 4144 5936

Прошу учесть что речь идет о самых гнусных условиях т.е. рендомное чтение и запись блоками различного размера. Линейны скоростай заходили за 40К!!!

Падение на запись наблюдалось где-то около меся, раза в 4, но тем не менее оставалось больше чем на SAS 15К рпм дисках, причем в несколько раз, а удельная стоимость гигабайта на сегодня:

55 центов на sas(беру segate) и около 90 центов(Intel).

Получаем оптимальную схему работы:

SAS 15K - несущие диски + SSD кеш на чтение и на запись (например LSI контролер умеет такое) + SAS 7200 большого размера для резервирования(РАИД 5-6) и храннеия файлов(РАИД10)

У нас сервер на ssd под vds

клиенты счастливы

Главное

RAID

бекапы

ну и не OCZ - мы используем team gold edition

Вот перенес еще одного клиента на SSD. До этого жил и не тужил на обычном sata-диске безо всяких рейдов.

Но в последнее время трафик возрос и все чаще начали наступать моменты, когда просто диск не успевал вовремя обрабатывать запросы (база на десяток гиг и на сотню гиг мелких файлов) и сервер сходил с ума с LA 200-250... Оптимизация и рестарт - лишь на первые пару часов были эффективны. Потом опять затык и лавиннообразно возникает очередь. Винт работал на чтение 26-28мбайт в сек.

После переноса всего добра на 240гб (для надежности 2 ssd поставили в зеркало) - нагрузка на файловую подсистему упала практически до нуля. Если раньше wa = 80...96%, то теперь всего навсего = 2...11%.

ЗЫ: за неименеем железяки - рейд выбран программный. При сборе рейда выдавалась скорость = 200...230 мбайт\сек. Теперь осталось мониторить состояние рейда и в случае каких-либо изменений - слать мыло. :)

За полгода потеряли один OCZ. Честно, не разбирались, что куда и как, даже по гарантии не меняли. Кинули резервный, пока работает.

Я вообще, почему то предпочитаю больше SATA 3 6Gbs. :)

Кстати от роста нагрузки помогает горизонтальное масштабирование

Небольшая правка кода и сайт можно разносить по серверам

Офигительные истории. Ну да, небольшая правка. В каждом файле или еще похуже. Это только в презентациях так бывает.

SSD менять нынче дешевле.

Что касается конфигураций по каким-то причинам не поддерживающих TRIM, так если используется RAID1, то одному из дисков можно попеременно делать обслуживание. Обслуживание заключается в отключении от RAID и запуске hdparm --trim-sector-ranges. Эта опция доступна только в новой программе hdparm.

А на время сервисного обслуживания система хранения подвергается повышенному риску.

1) остаётся один диск в зеркале.

2) нагрузка на этот оставшийся диск выростает. во-первых параллельные операции чтения которые распылялись между винтами зеркала теперь идут в один винт. во-вторых оставшийся винт после сервиса помимо рабочей нагрузки поднагружается ещё и чтением, чтобы сделать ребилд отключавшегося винта.

Слишком рисковано, по-моему.

А операции чтения расхОдуют ресурс ssd?

klamas, нет, просто чтение будет медленнее работать, но вряд ли это станет ограничивающим фактором из-за и так высокой скорости.

Насчет риска - не поддерживаю. Эту операцию делать предполагается редко.

В конце концов, делать то что-то надо. Не поддерживающие TRIM файловые системы тоже бывают нужны.

Ну я и говорю, риска от этого не добавится, а скорости там на всех должно хватить