За последний месяц участилось количество обратившихся которые хотят подбирать компьютеры под 1С на основании "сервер должен обеспечивать столько то флопсов и столько то iops". Вы с этим согласны? Почему?

для справки - wiki:FLOPS - в них меряют вычислительную мощность, а точнее сколько операций с плавающей запятой в секунду выполняет данная вычислительная система

имхо - нет,
более узкие места - операции чиения-записи данных

(2) + но раз просят флопсы - дайте, Любой каприз за ваши деньги (с)

wiki:IOPS - оценка производительности дисков - обозначет среднее число операций (чтение/запись) в секунду

(0) имхо
не вижу прямой корреляции производительности 1С и единственного параметра оценки скорости работы дисковой подсистемы

(2) а есть разница между 2 SSD и 24 HDD , выдающим по одинаковому числу iops?

(6) для лучшего понимания: SSD к примеру имеют меньшее время отклика

(5)+1
больший эффект даст не делать сложных расчетов на таблицах значений в транзакции записи

SSD не страдают фрагментацией, но ухудшаются по скорости по мере заполнения (есть такое мнение)

а клиенты хотят замерять iops на реальных условиях или верят в оценку производителя?

(10) верят в оценку конечно

(11) тогда точно не правильно, о чем даже в вики написано)

Для скульных серверов вроде давно жесткие по iops смотрят
В чем проблема-то?

Да хз, тут можно теоретизировать много, но кроме реальных оценок на существующей системе тестами типа КИП и т.д. судить о производительности 1с анриал, имхо

(13) серьезно? ты не видишь проблем? а есть разница между 2 SSD и 24 HDD , выдающим по одинаковому числу iops?

к тебе прям приходят и выбирают именно между 2 SSD и 24 HDD?
или сравнивают 1-й HDD и 2-й HDD по iops?

(14) клиент хочет новое оборудование подобрать на основе оценок iops с сайта производителя БЕЗ НАГРУЗОЧНОГО ТЕСТИРОВАНИЯ

(16) не видят разницы вообще, лишь бы iops

(17) а много производителей дают свое оборудование на тестирование?

(19) умные - все

хз, что-то как-то не видел предложений протестировать готовый сервер да и еще с запасом запчастей для варьирования по различным рейдам

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

(17)клиент хочет обосновать покупку дорогого железа чтобы получить откат
тебе до этого какое дело?
в (5) ответили уже. если это политический вопрос сам думай что им сказать чтобы потом не попасть, если это технический вопрос то переформулируй так чтобы было что обсудить
иначе (5)

(21) чот я поторопился, готовые сервера - тоже не видел, обычно клиенты дают на тесты купленное, после чего апредить по результатам тестов.
Отдельные компалектующие - дают тестить производители

(23) я консультирую. клиент хочет считать в иопсах, потом идти сам на рынок и чего-нидь самостоятельно взять

(22) кто потом ответит, если после покупки и сборки тесты покажут другую производительность? )

(26) да не должны, на амазоне достаточно всё точно, сам конфигуриш железяки и ПО

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

(25)короче глядя на фотку в личке и помятуя добро оставленное вами в инетах осмелюсь доложить что мое ИМХО сводится к тому что лучше несколько 10 рейдов по 4 диска в каждом и грамотно распределить свопы, темпы и прочие логи
(и не забыть интерлеаве моде на серваке включить (это о памяти))
а взять 4 быстрых винта и заставить их заниматься всем и сразу нет смысла никакого, ну о том что виндовый и скульный сервер нужно настраивать наверное не мне и не вам объяснять

(25)ну да а тебя вписать на всякий случай.
пусть развлекается, но связи прямой нет

(28) собственно вот, не сразу заметил как проголосовать )))

Demiurg,
1) имеются в виду МЕХАНИЧЕСКИЕ диски?
2)Файловая 1с ?

(32) клиент-серверный вариант, субд не известна

1) имеются в виду МЕХАНИЧЕСКИЕ диски?

мне хочется понять, откуда "ноги растут", это "из методички МГТУ имени Баумана" что ли

(34) чего не понятного, имеется ввиду iops нужно сказать заказчику, а он потом решит, SSD или шпиндели или еще что

(35) почитали о производительности железа, решили что данные показатели важные самые, не знают что такое нагрузочное тестирование 1с

(35) из маркетинга походу

(38) походу настолько хорошо, что с меня теперь спрашивают логическое обоснование, как это маркетологи решили, что оно так работает. Мой вариант что флопсы нельзя применять -  клиент говорит "не приемлемо". Надо во флопсах и иопсах, иначе низя :)))

(39) нафига клиенту консультант, если он его не слушает?

примерно так и спросил "а вы вообще нашим консультациям доверяете?" :)

(41) бери деньги и беги)

знающие люди также пишут что с ssd еще другая тема - http://www.thg.ru/storage/obzor_ocz_vertex_4_128_gb_test/obzor_ocz_vertex_4_128_gb_test-01.html#ocz_vertex_4_128__15_hd_tune_hiomon_disk_io_ranger - скорость падает с течением эксплуатации и по мере роста ) Какие Iops-ы в этом случаи заказывать? :)

(43) это в вики написано тоже, там перечень недостатков и плюсов SSD

сколько про SSD читал - таки думаю что hdd получше для серверов, ssd надо периодически менять, недешёвое удовольствие

(45) смотря что важнее, мы - меняем

(43) Demiurg
да есть такое падение, но даже в самом худшем случае SSD рвет HDD.

(45) Maxus43
про надежность
у нас отпахали 1.5 года SSD Intell (SLC) под БД (УПП)
сняли протести... утилита сказала НОВЬЕ))

(47) у нас 10 месяцев vertex 3 под боевой нагрузкой отпахали, базы сотнями гигабайт и как новый (тьфу-тьфу).

(47) оки, буду считать что минусов меньше)

короче я Выбираю "Другое"
т.к. Клиент-Серверная 1С 8.х зависит от:
1)скорости работы CPU
2) скорости работы с оперативкой
3)коммуникационно среды передачи данных "СУБД"<--"Сервер 1с"
4)Дисковая система

т.е. Диски всего лишь Часть Целого))

(50) диски всегда только Часть целого, в т.ч. и для файловой. для этого и нагрзочные тестирования делают)

(51) Maxus43
добавлю вам еще плюс от SSD ))
про MS-SQL , если база на 1-ом SSD -диске -

1)скуль меньше проц грузит, чем на RAID 0 на sas дисках.

2)притом за тоже время на ОДНОМ SSD больше в 6 раз транзакций успевает сделать.
http://ru.intel.com/business/community/index.php?automodule=blog&blogid=143&showentry=3067

+ (52)
хотя неопытный Админ глянув на счетчики Очередей SSD диска решит что он(диск) не справляется))

Этот параметр имеет не менее важное значение, нежели линейная скорость и скорость доступа. Однако ориентироваться только на значение IOPS неправильно.

(54) да много важных параметров :) вот поэтому оценивать только по одному опасно, тем более что я чаще смотрю на время отклика

(0)Фигня все это, никакой жесткий диск не выдаст столько IOPS как SSD, а если нет разницы, зачем платить больше?

(56) http://forum.infostart.ru/forum24/topic68077/ возможно...кому-то... :)

мне тут заказчик показал где он вычитал про иопсы http://ko.com.ua/monitoring_i_optimizaciya_diskovoj_podsistemy_servera_66663

Некоторые используют SSD для работы. Но это риск.

(59) т.е. ты думаешь что между  2 SSD и 24 HDD разницы нет при тех же iops-ах?

(60) iops-ы - это скорость работы с данными. В больших системах iops-ами и меряют производительность, а не типами рейдов и дисков.

(61) иопсы не единственная характеристика, которая оказывает влияние на конечный результат в 1С
существует время отклика
линейная скорость
и т.п.
еще раз задам вопрос:  2 SSD и 24 HDD разницы нет при тех же iops-ах?

(62) "существует время отклика линейная скорость..." - и всё это в конце концов влияет на iops-ы

(63) между  2 SSD и 24 HDD разницы нет при тех же iops-ах?

(62)"2 SSD и 24 HDD разницы нет при тех же iops-ах" - разумеется нет (при условии  что скорость чтения записи равна)

Только вот не будет у 24 HDD столько иопсов.

И еще - существует два фактора, линейная скорость, и iops.
Все.
И никакого времени отклика. Время отклика всегда равно 1 iops.

(65) время отклика есть всегда и у SSD

поскольку в моем вопросе сказано что у 2х SSD и 24 HDD одинаковое суммарно количество iops, то пытливый ум мог сделать вывод что математически это означает разницу в других характеристиках :)))

1. Статья, кстати, не тупая. Несмотря на некоторые упрощения и некорректные обобщения. В ней явно написано: "Анализировать корректно Disk Reads/sec и Disk Writes/sec можно только с учетом текущей длины очереди Current Disk Queue Length и средней длины очередей чтения/записи Avg. Disk Read Queue Length и Avg. Disk Write Queue Length." Видимо заказчику лень даже статью внимательно прочтитать.
2. iops показателен только либо для примитивных систем (1-3 диска) - там всё равно нормально нагрузку сложно раскидать, либо для очень дорогих (когда ограничением может стать шина FC или storage processor).
3. Железо можно выбирать по iops в том случае, когда этот iops а) является ограничением б) применим для той нагрузки в которой будет эксплуатироваться система. Если "а" предсказать обычно возможно, то "б" - сильно зависит от условий.
Вообще о каком сервере идёт речь? 1С:Предприятия или СУБД? Какой СУБД? Какой сервер 1С (64/32, какая ОС, если винда, то какой редакции, особенно, если памяти больше 32ГБ :) )
Если навскидку, то у сервера 1С следующие заметные дисковые активности:
* ЖР - только последовательная запись, актуально если не отключен и если много изменений в данных.
* Временные файлы больших выборок - последовательная запись большого файла и последовательное чтение, но при большом количестве пользователей может быть несколько одновременных потоков (актуально скорее для отчетов и сложных алгоритмов)
* ТЖ - это скорее тестовые стенды и сервера разработки.
Для MS SQL:
* Последовательная запись при изменениях в журнал транзакций при правильной настройке сервера (т.е. достаточном размере заданном сразу). Простая модель восстановления не исключение (при обычной работе 1С). Часто является ограничением производительности, потому что выполняется в Write Through.
* Массовые случайные чтения файлов данных небольшими блоками при выборках (при хороших планах запросов). Глубина очереди может стать очень большой.
* Массовые чтения файлов данных где-то случайные, где-то последовательные блоками разного размера при плохих планах запросов. Глубина очереди будет очень большой.
* Массовые последовательные операции чтения и записи файлов данных и ЖТ с небольшой глубиной при резервном копировании. Да и при перестроении индексов похожая нагрузка. На хорошей дисковой системе и мощном железе можно упереться в шины и производительность дисковых процессоров.
* Случайные записи файлов данных при изменениях данных. Если памяти достаточно, то это НЕ является ограничением само по себе, так как для файлов даннх работает отложенная запись. Но вот при комбинации нагрузки (грубо говоря, когда есть очередь на чтение и на запись) может опечалить заказчика.
* Нагрузка на файлы данных tempdb (сильно зависит от запросов и объёма памяти)
* Нагрузка на файлы ЖТ tempdb - чтобы было ограничением я не встречал, но повлиять на другие нагрузки может

А теперь всё вышенаписанное смешиваем :) Учитывая, что:
* смесь случайных операций и последовательных даёт плохо предсказуемую производительность (в iops, конечно же)
* смесь больших и малых блоков даёт плохо предсказуемую производительность
* при больших глубинах очереди производительность плохо предсказуема
* смесь Write Through и Write Back - плохо предсказуема

4. Если заказчик так и молится на свои несуществующие иопсы, то пусть и требует этих иопсов с вендора. В зависимости от того, сколько заказчик платит на консультацию можно даже собрать стенд на простейшем железе (хоть в виртуалках) с отдельными дисками для каждой нагрузки и снять замеры СНТ или его реалистичной нагрузки с отслеживанием по apdex (параметры: средняя очередь, количество записей в секунду и чтений в секунду, снимать раз в 1-2-3-4-5 секунд). Те периоды, когда средняя очередь хотя бы на одном диске больше 1, потенциально ускоряются от дисковой системы. Считаем сумму операций ввода-вывода N за эти периоды суммарного времени T1, если всё время T0, то тупо арифметически говорим, что если при призводительности K iops общее время выполнения сценария будет (T0-T1) + N/K, где (T0-T1) зависит не от дисковой подсистемы. Правда с высокой верятностью K iops будет недостижимо по причинам, изложенным, но это пусть у вендора трясёт, чтобы вендор обеспечил.

(57)Тестирование по ссылке вообще ниочем.
Памяти на всех трех системах очень много. (много по сравнению с размером базы).
Понятно что при таком объеме памяти, база будет закэшированна в памяти. Соответственно все остальные параметры типа скорости чтения, количества iops влиять практически не будут.
Будет влиять только скорость процессора и скорость работы с памятью.
Результаты тестов это наглядно показали.
Но в реальности он тоже будет работать с этой тестовой базой? Или все-таки база будет побольше?

Любой синтетический тест, при неграмотном использовании показывает погоду. Нужно либо досконально разбираться в тонкостях, либо тестировать на рабочей базе, полностью имитирую обычную работу пользователей.

(66)Объясни пожалуйста, что такое время отклика, и что такое iops, и в чем разница между ними?

>>>>хотят подбирать компьютеры под 1С на основании "сервер должен обеспечивать столько то флопсов и столько то iops".


так компы или сервер????

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

ВСЕГДА начинать нужно с топологии сети!!! правильный гигобитный линк между сервером 1с и SQL увеличит быстродействие сисемы в разы, но вот только в шнурке нету ни флопсов ни iops, скажы звказчикам пусть протестируют шнурок на эти показатели и приходят...

(68) iops отличается от времени отклика примерно как пропускная способность дороги от времени доезжания на работу.
Пока оченредь к диску постоянно есть и равна 1, то iops - величина обратная времени отклика, если очередь не 1, то это неверно.

(70)Время отклика - это время прошедшее с момента  запроса до получения/записи минимальной порции данных. Т.е это время операции ввода/вывода.
IOPS - количество операций ввода вывода в единицу времени.
При вводе выводе минимально возможного блока


Т.е время отклика показывает за сколько времени осуществляется одна операция ввода/вывода.
А IOPS показывает сколько операций ввода/вывода произойдет за единицу времени.
Понятно что при больших блоках значение iops будет падать, т.к оно будет больше зависеть от  линейной скорости чтения и пропускной способности интерфейса.
Поэтому замер IOPS информативен только при минимальном блоке.
Т.е мне достаточно знать IOPS на минимальных блоках, и линейную скорость, остальные параметры нафиг не нужны, ибо никак не влияют.


И причем тут очередь к диску?

Если клиент туп, продай ему самое дорогое

(71) минимальный блок - это кластер

требуется записать 3 кластера

пишем 232, 233, 234 - время 0.02с (условно)
пишем 232, 56432, 142 - время 0.1с (условно)

это пример одинаковой по размеру очереди, с разными результатами

(57)вообще для думающих тест ни о чем вообще

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

походу просто маркетинговый тест, приванный опустить заказчика сразу втерев ему очки на тему "ваше железо какашка"

ни многопользовательский режим ни учитывается ни потоковое перепроведение, ни ядерное безумие расчетов на таблицах значений в транзакции записи (проведения).

короче тест тестит. но под реалии 1с от него пользы как от iops

вообще обычно винты берутся тупо соразмерно стоимости сервака или его компонентов если он "собирается"
позволюсебе сообщить что большее значение имеет кеш винта, опять же при правильном распределении нагрузки на массивы, а так как у нас обыно настраивают систему так иногда вообще лучше отключить всякое кеширование или полностью перенастраивать как виндовый так и скульный сервак, я бы даже сказал начиная с пересобирания рейдов

(74)Естественно.
Тест показывает скорость работы тестовой конфигурации в режиме тестирования на данном компе и ничего более.
У реальной конфигурации при реальной нагрузке будет совершенно другие показатели.

"короче тест тестит. но под реалии 1с от него пользы как от iops" - от iops польза есть, и большая, но только в том случае, если именно это является узким местом.
Если узкое место в другом, то совершенно пофиг на характеристики диска.

(74)
>"походу просто маркетинговый тест, приванный опустить
> заказчика сразу втерев ему очки на тему "ваше железо
>какашка""

не совсем так)) КАКАШКА - это реализация взаимосвязи
"Сервер 1"<-->"SQL" - разрабами плотформы 1С.

Грубо говоря "Сервер 1С" = "Объектная СУБД"

Нафига "Объектной СУБД" работать с НЕОБЪЕКТНОЙ СУБД?

я вижу два Пути решения)):

1)ВСЮ логику перенести на SQL и не использовать язык 1С ВООБЩЕ... а использовать только внешний вид Клиентской части))  
ИМХО -- это ппц какой сложный вариант для прогеров разработчиков бизнес логики Программы.

2)Фирма 1С - разрабатывает свою ПОЛНОЦЕННУЮ ОБЪЕКТНУЮ СУБД на основе "Сервера 1С" с полным отказом от внешних СУБД - вот этот вариант - мечта конечно)) но вдруг все-таки....

+ к (77)
пордон есть еще вариант))

3)использовать внешнюю Объектную СУБД
например - "Cach?"
Единая архитектура данных Cach? позволяет разработчикам
>использовать ОБЪЕКТНЫЙ или РЕЛЯЦИОННЫЙ или ПРЯМОЙ доступ к
> одним и тем же данным

http://lusindane.at.tut.by/files/object00.html

Да это же новый бизнес.
Сервера под 1с.
1. Даем броскую рекламу в бух. журналы и журналы дириков.
2. Даем эффектную текстовую рекламу на мисте.
3. Толкаем в тридорога сервера с наклейкой 1с совместимо.
4. Профит.
НЕ?

(64) Вячеслав, вы же знаете что это не одно и тоже, даже при равных IOPS.

(80) меня интересует "мнение народа" :), я то знаю