все по 500G. Если по вашим словам предположить средний объем прироста информации 20мбайт в секунду, то при условии традиционного использования описанного массива в конфигурации допустим raid10 с уменьшением объема в 2 раза (24*500*1000*1000*1000/2 ), вам хватит на работу хостинга в течении (24*500*1000*1000*1000/2)/(20*1024*1024) cекунд , то есть за 286102/(60*60*24) = на 3 дня ? это точно хостинг?
Я думаю, вам сначала следует узнать, что за приложения вас перезаписывают данные и почему в таком объеме, а потом уже ускорять хранилище. Наверняка чем-то можно пожертвовать. ---------- Добавлено 28.05.2012 в 16:27 ----------
Должен проявить. Он же работает и при записи тоже. Я считаю, что все адекватные столько не перезаписывают, хотя точной статистики у меня нет. Я пытаюсь интерполировать статистку обычных, хоть и посещаемых проектов, с которыми я работаю.
Неужели глупое увлечение плагинами кеширования html в джумлах имеет такие масштабы ? Почему рост объема записи не ограничен нехваткой других ресурсов на таком сервере? хотя бы CPU
hvosting, опять 25. 24 каких именно моделей диска? кроме картинок там 7 разных моделей дисков.
---------- Добавлено 28.05.2012 в 12:42 ----------
А это у всех адекватных хостингов так. Тут нет ничего особенного.
hvosting, и что это ? дисков-то сколько и в какой конфигурации raid ? картинки мне ни о чем не говорят.
Вообще, для любой сколь угодно хорошей технологии можно найти неудобные условия работы. Это не значит, что тут же следует всем советовать отказаться от нее.
hvosting, что-то вы привираете. какой же массив переваривает такой объем случайных операций записи ?
никакого кеша raid , очевидно, тоже не хватит, если ssd не хватает.
Это чем посчитано 30 мбайт/ сек? график есть ? Это точно shared-хостинг типичных проектов? Сколько сайтов ?
Люди столько текста не набирают. А если у вас возникает необходимость сохранять не текст, то у вас не хостинг, а нечто специфическое.
Тут совсем надо осторожно с SSD, потому что еще и вероятность износа намного выше обычной будет.
Если SSD не успевает "стравить" эти 30мбайт/сек, то как обычный массив-то справляется?
hvosting, а зачем долго и упорно? Это и есть неправильная методика. Тест должен быть близким к реальным потребностям хостинга
Разумеется, когда на ssd много грязных блоков, возня по их вытеснению становится сложнее чем просто запись на основной диск. Какие-то там были новые оптимизации последовательной записи больших файлов вроде.
Из аргументов tiobench по ссылке должно быть видно, что он 10 гбайт нагенерил за короткий период. Да, это меньше размера ssd. Но а больше-
то зачем ?
Если клиентский проект создает файлы со сравнимой скоростью, то его следует вытравить с хостинга. И этот навык у всех хостеров отточен.
Хостер, а принципиально ничего там не поменялось. Скорее вопрос к вашей методике тестирования. Может вы вообще в битриксе циферки пытались смотреть?
Или вы могли изначально не настроить кеширование записи. В синтетических тестах-то все отлично . Я тут публиковал даже : /ru/forum/comment/9763468
На практике у меня не было возможности замерить показатели одинаковых сайтов до SSD и после. Их переносили вообще с других серверов. То, что стало быстрей, это и так понятно.
А то что?
И вообще: бизнес - это риск. кто не рискует, у того норма прибыли обычная. Гарантировать, что flashcache будет работать в сотнях инсталляций годами на разных ядрах и дисках просто некому из-за инертности хостеров.
Я использую где-то с полгода и все нормально.
И каких же именно ? Вполне возможная ситуация, но конкретизировать неплохо бы.
А зачем вообще об этом думать? Тем более, что выбирают они не по скорости диска.
Вы просто сможете больше пользователей впихнуть на одну ноду без негативных эффектов. Разумеется, я имею ввиду конфигурацию где SSD работает как кеш большого диска.
Нет, слишком узкая задача потому что все сайты разные.
Но никто не запрещает написать такой прокси для вашей задачи. В конце концов, те, кто написали поискового робота, легко справятся и с авторизацией.
