Модернизация сервера под 1С 7.7

[gs]

Не понял. Ничего не понял.

Где мы советовали делать рэйд5 под БД?
Какой бред - насовывать полтора десятка сата винтов, да еще в рэйд5 под базу?
Ошибки дисковые - никакого отношения к предмету обсуждения не имеют, это просто обычная техническая проблема, которую надо решить. Странно, что Вы этого не сделали, да еще в пример приводите...

[-=Жека=-]

Наверно придется рассказать азы.
1. Мощь современных контроллеров (и даже предыдущего поколения) превосходит предельные иопсы всех подключенных к ним дисков буквально в разы.

+1

2. Согласно п.1, при наличии современного и правильно сконфигуренного контроллера, производительность системы упирается в шпиндели.

ну наверное да. хотя не до конца.

3. Раскладка нагрузки, имеющей примерно одинаковый характер, по разным массивам существенного эффекта не дает. Контроллер сам прекрасно способен разобраться куда, когда и что писать. В редких случаях некоторые контроллеры предпочитают работать с массивами из малого числа дисков (так фирмварь написана), но это игры на уровне +-10%, к тому же зависит от КОНКРЕТНОЙ модели контроллера и характера нагрузки - угадать сложно.

у здесь не совсем всё гладко. Bulk insert по 20000 записей в секунду не одно и тоже по сравнению с select из 200 000 000 записей.

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

не все контроллеры это умеют.

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

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

6. Эффект разнесения по массивам начинается при существенном количестве дисков (хотя бы десятка полтора и больше). Там уже не так велик риск "не угадать". К тому же много винтов в один лун все равно не влезет - когда речь идет про десятки шпинделей, разносить нагрузку приходится само собой. И там это вполне оправдано.
7. Размер кэша - не панацея. В большинстве случаев вполне достаточно банальных 128МБ. Суть в том, что кэш глотает только всплески нагрузки, а в конечном счете винты все равно должны успеть это проглотить до следующего всплеска. Т.е. какой бы ни был кэш, если винты не дают нужную сумму иопсов, то получим ровный график дисковой очереди в десятки-сотни единиц.
8. Разнесение дисков-массивов по каналам контроллера при транзакционной нагрузке с точки зрения скорости ВООБЩЕ не имеет никакого значения. Несколько каналов нужны контроллеру только чтобы подключить много дисков без риска нарваться на нестабильность шины или другие канальные проблемы.
9. ИТОГО. Для увеличения дисковой производительности нужно просто много дисков в рэйд10 и достаточно мощный контроллер. Все остальные игры - это из области куда более серьезных систем.
10. То, что Вы говорите автору - это не советы, а просто фигня какая-то...

[a_shats]

Запустите анализатор трафика на сетевом интерфейсе и посмотрите что делает 1С когда работает с шарой(например tshark,ethereal). Вы сильно удивитесь. особенно в мультипользовательской работе по сети.

Я ? Отнюдь. Но сеть - одно дело, дисковая - другое, и смешивать их в кучу - не надо.

Кеширование имеет место быть. В памяти живут не все данные.
Речь изначально шла о том, КАК заставить нормально работать 1C SQL + 1C DBF на одном сервере с 3Гигами рама и SQL базами превышающими доступную физическую память. Когда речь идет об одной базе никаких проблем нет. Я же говорю о 50-100 рабочих базах расположенных на одном сервере.

Ну и ради БГ. Чудес-то не бывает - нагрузки можно парировать только адекватным железом, и наилучший вариант - сочетание достаточного объема ОЗУ и достаточно высокопроизводительной (в рамках задачи) дисковой подсистемы. Ну или долгим и упорным ручным затачиванием конфига 1С. Причем тут 50, 100 или 1000 баз - не понимаю совершенно. Потому как количество баз как таковых большой роли не играет, играет - нагрузка на них.

no comments. речь не об этом.

А о чем ? Речь о свопе именно Вы завели.

В данном посте речь шла о 2х SCSI дисках на 36GB. Я не занимаюсь разработкой контроллеров хотя по образованию схемотехник. Мне хватило во времена моей учебы в вузе делать то, чего не могли до меня сделать в течении 5 лет.

Эээээ, Вы куда-то не туда уруливаете. Предложено было адекватное решение, а Вы - именно Вы! - безапелляционно начали заявлять о том, что все ерунда, а надо делать "так". К чему Вы тут сейчас притянули 2хSCSI винта - я не понял.

проведите эксперимент ради интереса. возьмите 30 бухгалтеров которые будут работать в 200 базах в общем доступе на обычном сказевом зеркале )

В каком месте я рекомендовал сказевое зеркало на 30 клиентов ? Покажите пальцем плиз.

Но !
Использовать RAID5 для записи-чтения Transaction Logs это глупо и расточительно. Использовать RAID5 для хранения баз скорее правило надежности, хотя не для всех правила являются руководством к действию.

 Это почему ? Первое чушь потому, что логи пишутся потоками с блоком 2 КБайт и берстом 2 блока, количество потоков = кол-ву баз, к которым эти логи пишутся. Почему нельзя использовать RAID5, наиболее эффективный с т.з. объема уровень, если производительности контроллера хватает ? Непонятно.
Второе еще смешнее. Почитайте форум. Именно из логов perfmon мы неоднократно убеждались и убеждали других, что у 1С при работе с дисковой соотношение чтения к записи примерно 50/50. И потому рекомендовали RAID10.

Теперь по поводу 16 дисков на контроллерах.
у меня стоят 2 SuperMicro платформы на 15 хардов с 3ware 9550SX-16 на борту. Одна из платформ забита под завязку, вторая на 2/3.
Так вот есть интересный факт, при залитии туда SQL ных баз ежедневно в размере до 100 гигов за раз, после ночной проверки контроллер матерился на ошибки найденные и исправленные на дисках. Это было на RAID5 в большом количестве, и в меньшем на RAID10. После того как количество файлов на RAID5 собранном на 8 дисках перевалило за 2.5 миллиона скорость доступа к файлам заметно упала. Дефраги уже не помогают. Результатов тестирования IOmeter'ом я так и не дождался.
Дабы не быть голословным по поводу 1С, ниже скриншот с папки с базами.

Вы пытаетесь использовать наихудший вариант дисковой подсистемы относительно задачи - и кто после этого Вам доктор ?
Ваши 16 винтов SATA 7200 rpm в этой задаче эквивалентны примерно 6 винтам SCSI/FC 10К rpm или 3 х 15К rpm.

[gs]

Еще раз.

С точки зрения дисковой системы абсолютно по барабану какие именно операции проводятся в базе. Ее интересует только характер нагрузки - рандомный (характерно для ОЛТП) или более-менее линейный (в некотором смысле характерно для ОЛАП). И все.

Резать массив на луны превосходно умеют адаптеки. ЛСИ тоже может, правда с рэйд10 там нехорошо. У тривари плохо, но она не для таких задач собственно. Во внешних же системах это бай дизайн. В общем, надо просто правильно выбирать контроллер.

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

[-=Жека=-]

Не понял. Ничего не понял.

Где мы советовали делать рэйд5 под БД?
Какой бред - насовывать полтора десятка сата винтов, да еще в рэйд5 под базу?
Ошибки дисковые - никакого отношения к предмету обсуждения не имеют, это просто обычная техническая проблема, которую надо решить. Странно, что Вы этого не сделали, да еще в пример приводите...

ну это же не я написал ?

Собственно если мои предположения верны и цифры я правильно прочитал, то вам пора бы подумать о внешней полке к серверу. То бишь пара 5150 процов, 8ГБ памяти + Заратекс с дисками. В противном случае если мы сейчас подберем серверок скажем даже с 16-ю сказевыми дисками, то через год - полтора все-равно упретесь в производительность дисков. Бюджет какой? Можно стукнуться мне в аську, 116164373. Я вам отвечу

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

Ребят я не наезжаю ни на кого, просто я предложил решение которое было встречено в штыки. Это неправильно по отношению к людям которые сюда заходят. Это похоже на "у меня есть своё мнение, остальные неправильные".

Указанная мной конфигурация для 1С живёт на брендовом сервере
5x73GB SCSI+HS на RAID5. Затюнен tcp/ip стек. SQL базы 1С лежат на том же диске что и файловые базы и это всех устраивает ибо SQL базы меньше чем память в сервере. Сервер не терминальный.

По поводу разнесения дисков для SQL баз. DATABASE сервер с 8 гигами памяти и 40 Гиговыми базами до установки полки затыкался при большом объеме транзакций. После установки полки и разнесения временных баз, логов и основных баз с системой скорость работы увеличилась втрое.

Терминальные сервера я настраивал еще в 2003 году насколько я помню, и сейчас человек который работает после меня имеет теже самые проблемы с производительностью что и автор коренного поста.
Именно 1С в терминальном доступе.

[a_shats]

ну наверное да. хотя не до конца.

Как это ?  :shock:

у здесь не совсем всё гладко. Bulk insert по 20000 записей в секунду не одно и тоже по сравнению с select из 200 000 000 записей.

А зачем Вы сравниваете, извиняюсь, Bulk с пальцем ? Массовую запись с выборкой на чтение ?

не все контроллеры это умеют.

gs и написал, что это имеет эффект невысокий и довольно сомнительный.

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

А теперь прочитайте еще раз то, на что Вы отвечаете, и то, что Вы ответили

[a_shats]

Ребят я не наезжаю ни на кого, просто я предложил решение которое было встречено в штыки. Это неправильно по отношению к людям которые сюда заходят. Это похоже на "у меня есть своё мнение, остальные неправильные".

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

[-=Жека=-]

ну наверное да. хотя не до конца.

Как это ?  :shock:

у здесь не совсем всё гладко. Bulk insert по 20000 записей в секунду не одно и тоже по сравнению с select из 200 000 000 записей.
А зачем Вы сравниваете, извиняюсь, Bulk с пальцем ? Массовую запись с выборкой на чтение ?

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

не все контроллеры это умеют.

gs и написал, что это имеет эффект невысокий и довольно сомнительный.

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

А теперь прочитайте еще раз то, на что Вы отвечаете, и то, что Вы ответили

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

зы: Трое ваших сотрудников меня очень хорошо знают есличто
Им пламенный привет !

ззы: я мнение обосновал. наш нынешний DBA работал с SQL базами выше 100 гигов и он знает что говорит. Везде есть свои особенности.

[gs]

Базы свыше 100ГБ как правило живут на серьезных железяках, где много дисков. Там разнесение логов более чем оправдано. См. мои посты.
А что после установки дисковой системы с кучей дисков стало лучше - это как бы само собой разумеется. Она даже без нарезки массивов дала бы колоссальный эффект. А с разнесением - еще немного побольше...

[-=Жека=-]

Базы свыше 100ГБ как правило живут на серьезных железяках, где много дисков. Там разнесение логов более чем оправдано. См. мои посты.
А что после установки дисковой системы с кучей дисков стало лучше - это как бы само собой разумеется. Она даже без нарезки массивов дала бы колоссальный эффект. А с разнесением - еще немного побольше...

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

[a_shats]

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

Да не вопрос, но девчонки вне тематики данного форума  :D

зы: Трое ваших сотрудников меня очень хорошо знают есличто Им пламенный привет !

Вам тоже от них привет, мы в курсе.

ззы: я мнение обосновал. наш нынешний DBA работал с SQL базами выше 100 гигов и он знает что говорит. Везде есть свои особенности.

Мнэээ.... Если бы все DBA, работавшие с БД более 100 ГБайт, были..эээ...высококвалифицированными (я на данный момент ни на секунду не сомневаюсь в квалификации Вашего ) - у нас было бы НАМНОГО меньше проблем в работе с клиентами

[a_shats]

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

Сдуру можно не только массив сломать
Сильно зависит от задачи, на самом деле.
Не сильно нагруженный биллинг, к примеру - это одно, OLTP БД с соотношением записи к чтению в районе 50/50 - совсем даже другое.
С точки зрения потребного кол-ва IOps. А вот это самое кол-во почти прямо пропорционально числу шпинделей, задействованных под задачу.

[-=Жека=-]

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

Сдуру можно не только массив сломать

Сломать-то можно, а вот починить

[Stranger03]

Наверно придется рассказать азы.
1. Мощь современных контроллеров (и даже предыдущего поколения) превосходит предельные иопсы всех подключенных к ним дисков буквально в разы.

+1

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

[pоmkа]

Что по такой конфигурации думаете?

2X CPU AMD Opteron 2.0 ГГц BOX (без кулера) (OSA2212) 2Мб/1000 MHz Socket-F
M/B TYAN S2927A2NRF Thunder n3600B(RTL)DualSocketF <nForcePro 3600> 2xPCI-E+2xGbLAN+1394 SATA RAID U133 ATX 8DDRII
4X Kingston <KVR667D2E5/1G> DDR-II DIMM 1Gb <PC-5300> ECC CL5
Controller Adaptec ASR-3805/128 (OEM) PCI-E x4, 8-port SAS, RAID 0/1/1E/10/5/5EE/6/50/60/JBOD, Cache 128Mb + Батарейка
4X HDD 73.5 Gb SAS Fujitsu <MAX3073RC> 15000rpm 8Mb
Server Case SuperMicro <CSE-743TQ-650B> 8xHotSwap SAS/SATA, E-ATX 650W