На сервере терминалов с 12 гигами мозгов, Xeon X3440\ установлен райд контроллер Adaptec Raid 51245\на нём объеденены в райд 0 (страйп) (в дальнейшем переделаю в 10, после того как будут носители, сейчас нужен результат) 5 ССД дисков со скоростью каждого 250 мегабайт в секунду...т.е скорость массива получилась порядка 1 г\с....на сервере в терминальном режиме работают 40 пользователей (база 4 гигабайта DBF)... постоянное ожидание захвата таблицы, при обычных винтах в програмом райде такого не было ... даже при скорости 150 мегабайт в секунду.. что может быть? база не типовая, уже во мнго переработанная нашим программером...на 8ку и SQl перейдём лишь со следующего года...

базы на ССД держать, не ссыкатно ?

Контроллер, имхо

наверное рейд не в курсе что его теоретическая скорость 1 г/с... наверное он считает по-другому.

х..во написана конфа

2(4) она волшебным образом становится х..вее когда чувствует, что работает с более быстрыми дисками?

а, стоп.. еще и 77?

да база пока 1С 7.7...руководство решило на 8ку только с 2012го

(5) Т.е. туже базу перекладываем на другой диск и все ок?

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

(8) ну ТС пишет же "при обычных винтах в програмом райде такого не было ... даже при скорости 150 мегабайт в секунду.. что может быть?"

Скорее всего виноваты недавние косяки вашего недопрограммера

(10) ключевое слово БЫЛО

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

>>руководство решило на 8ку только с 2012го
они не верят в конец света? :)))

(5) Бывает такое. Знакомы  2 раптора в райд-0 для мкорости ставили, так база на нем работала медленнее, чем прост на одном рапторе

ладно, мои посты вычитайте, я все равно тут теоретик.. :)

брали ССд с надеждой что скорость решит броблему с работой в дбф базе... но пока не оправдывает

сейчас вот думаю дождаться завершения рабочего дня и в контроллер воткнуть обычные САТА... другого выхода пока не вижу...

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

"базы на ССД держать, не ссыкатно ?" а почему нужно бояться?

а нормальные дисковые тесты погонять на этом чудо рейде не пробовали?

2. поставить время ожидания таблиц в 0 - это стандарная рекомендация для терминальщиков
1с - меню - сервис - параметры

(17) приглядитесь к PCI express SSD типа такого
http://www.nix.ru/autocatalog/ssd_ocz/OCZ_OCZSSDPX1RVDX0360_Revo_Drive_X2_PCIExpress_SSD_360_PCIEx4_MLC_116407.html

(0) В конфе ничего не меняли последнее время? Ничего не перепроводите? Как там у вас с блокировками?

Семерка она при проведении даже захудалого дока блокирует журнал и все ждут

http://www.abelov.com/forum/f.php?pg=0&id=82551 ssd рекомендуют ставить только на pci-e другие просто шины не птянут

(0) вчера на THG чтоли, селали рэйд0 из 12 ссд, 15 гигабайта получилось. это так, в качестве оффа

по сабжу - поставь приблуду от ромикса - должно быть оно в проц упирается.

(26)+ переписывай на прямые запросы

* 1,5 гигабайта

"приглядитесь к PCI express SSD типа такого "
проверенно брал почти такой же но на 480 гигов... при 15 пользователях скорость чтения записи падает до 15-50 кбайт... не вариант

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

контроллер установлен в PCI-E... конечно же...и кэширование у ССд отрублено..

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

а что про (22)?

ставил... если при 15...новая реализация ещё открывается, то при 0.. вообще нет.. постоянно ошибка журнала

(34) приблуду от ромикса ставь. а вообще - походу глав бух на вопрос о восстановлении последовательности в отчетах нажимает "да" :)

>>база 4 гигабайта

Что мешает перейти на скуль?

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

"походу глав бух на вопрос о восстановлении последовательности в отчетах нажимает "да" :)" ...
всегда нажимает ДА... и уезжает обедать...

(37) посмотри, что в журнале регистрации творится, 80%, что (35). поможет Книга знаний: Исправление ошибки 1С:Предприятие 7.7/8.0 - 100% загрузка процессора при ожидании блокировки

(34) тут 2 варианта, либо (22), либо (35)
но лучше (22)
-------
у тебя не жесткие диски тупят, а процов не хватает, т.к. при блокировке 1с грузит 1 проц на 100%

(38) прострели ей коленку

(38) гыыыыыыы

йа, сука, телепат

Ожидание захвата таблицы в 1с 7.7 практически не зависит от скорости винтов. Нужно базу смотреть... Может вы там предупреждений в модуль документа нафтикали...

(44) => (38)

проц курит бамбук не напрягается вообще... процентов на 20 максимум загружен...
оперативка 2,5 гига занято.. остальное свободно

(40) Дело не в процессорах а в блокировке журнала документов с дедлоками

(46) Тут дело общей организации данных... А не в железе...

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

Вот статья http://www.softpoint.ru/article_id1.htm

Не принципиально что там про скуль

если не зависит от винтов, то почему такая разительная разница в работе? на HDD и на ССД при одинаковом количестве пользователей... ?

(49)+ ну или главбухше объяснить, что так делать не надо

(51) потому что раньше упиралось в ХДД, а теперь - в проц, натурально. ну и кстати, нафига кэш вырубил?

на ССД КЭШ ни к чему...по крайней мере всю мукулатуру то перебрал ясно на это намекает.. всё же ССд это практически оперативка

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

(54) "намекают"? 14летние задроты на форумах, у которых только они одни за компом?

на этом серваке системка крутится на http://www.bestmemory.ru/goods/id8760000.html

Стирание информации в SSD происходит довольно крупными блоками, поэтому есть эффект нового (или пустого) диска. Количество свободного места больше влияет на долговечность, но при его критическом недостатке и на скорость. Так же на это влияет поддержка и нормальная реализация функции Трим.

(57) Еще раз: дело не в железе.

(56) ...если оставляю КЭШ.. скорость чтения записи падает чуть ли не до 30 метров в секунду и вообще невозможно работать

(58) Трим в райде не работает

(61) вот потому и говорю, что для интенсивного чтения/записи и массивов ССД не подходит, пока, по крайней мере

+надежность

(59) сегодня всё же перетащу базы на HDD....это в любом случае придётся сделать чтоб народ мог норм работать завтра...и нашей програмерше задам вопрос.. может что придумает...

(64)
меняйте програмера.

ЗЫ могу оптимизировать вашу нетленку удаленно в обмен на железо из (57)

(65) скромные пожелания)))

(66) ну ладно... опускаю планку до 2-х ССД.

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

перекинул базу на другой комп... там райд 0 из 4х винтов... скорость 200 мс... 10 пользователей.. (просто попросил несколько человек погрузить базу)... ни разу не вышебло ожидания захвата....бред...зачем тогда скорость 1 гиг если по каким то причинам тормозит ССд....даже тот что под систему.. запустил тест на нём.. 2 м\с.. и это от 600-720 м\с по умолчанию..

(69) запусти что-то типа hd tune на обоих серверах и сравни результаты

Патч ромикса ставил?

Ясен пень что дело не в дисках. ты бы хоть перф монитор посмотрел

(69) В рабочей тоже 10 юзеров?

(72) судя по (69) с дисками тоже есть проблема.
хотя изначально - проблема явно не в дисках

дело в дисках, я тебе сразу сказал

(73) в рабочей 40, просто всех не стану же просить временно отвлечся на тесты...на ССД начал тормозить уже при 5ти.. так что на HDD хватит и 10и
(70) запускаю HD speed и сравниваю...
(71) vk_sleep_1c оно?

(75) думаеш стоит отказаться от ССД для базы данных?

(77) ИМХО еще технология не развита для массивов и большого числа циклов чтение/запись

(77) У тебя явно что-то с настройками.
Я сравнивал 10 рейд из 4-х САТА дисков и один (!) ССД. Так ССД был чуть-чуть быстрее в 1С (субъективно) на скульной базе. В ДБФ, теоретически, разница в пользу ССД должна быть еще больше.

(79) у меня наоборот все, ССД кингстон модель не помню, 120 Гб

(80) у кингстона только одна модель на хоть что-то похожа SNVP325....
остальное все УГ

(77) Для одного пользователя нет. Для 50, лучше скази еще ничего не придумали

(79)как было сказано выше (82) для одного пользователя один результат но когда 40-50 пользователей... там другие нагрузки...

а если я подниму страйп на HDD к нему зеркало на SSD... такой вариант ктонибудь пробовал?

(23) А в таком исполнение ССД можно в рейд массив собрать?

(85) PCI-E REVO 480 gb + 5 SSD 50 gb?

(78) т.е я поторопился с решением перевести базу на ССД?

как вариант действительно можно попробовать объеденить PCI-E REVO 2 720 м\с и 5 ССД в один массив, но даже если достигну 1,5 г\с ведь не факт что 1С у народа будет быстрее работать... да и как я смогу проверить вечером когда все уже ушли...т.е если я нагружу базу... это одно а утром придёт народ и начнётся всё поновой...

(88) Как таких людей к компам подпускают? Поиск узких мест начинается не с установки ссд

(89) предлагаете всё же копаться в базе? переводить на SQL? распределять базу? ..

(90) Предлагаю запустить перф мон и узнать РЕАЛЬНЫЕ узкие места

(91) шкала средняя длина очереди диска 100.000

(91) осталось 4 пользователя 1С летает....
очередь дисков 0... при народе был 53,000...

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

(94) OSZ SATAII 2.5" Solid Agility 2

ну что я убрал ССД диски...объеденил обычные SATA страйп...скорость показывало норм.. но тормоза в базе продолжались... отчёты долго формировались ожидание захвата таблицы...сейчас убрал REVO PCI-E c системного и поставил SATAшку...с неё и загрузился...скорость массива баз показывает 250-330 метров \ секунду... народ говорит что всё летает....где логика? почему системный диск так влиял на скорость работы базы?

своп?

(92) масштаб следовало поменять

а вообще кол ж ставит систему и данные на один контроллер?

*кто

Опыт фаната SSD

Друг компании и просто клевый парень Уиллс Портман может рассказать истории пострашнее. Он заразился религией твердотельных дисков после моего поста 2009-го года. За эти два года он купил восемь дисков и все они сдохли.

— Super Talent 32 Гб SSD, сдох после 137 дней
— OCZ Vertex 1 250 Гб SSD, сдох после 512 дней
— G.Skill 64 Гб SSD, сдох после 251 дня
— G.Skill 64 Гб SSD, сдох после 276 дней
— Crucial 64 Гб SSD, сдох после 350 дней
— OCZ Agility 60 Гб SSD, сдох после 72 дней
— Intel X25-M 80 Гб SSD, сдох после 15 дней
— Intel X25-M 80 Гб SSD, сдох после 206 дней

(102) копипастишь с хабры - копипасть полностью

(103) http://habrahabr.ru/blogs/hardware/119997/#habracut

— OCZ Agility 60 Гб SSD, сдох после 72 дней
— Intel X25-M 80 Гб SSD, сдох после 15 дней

это жесть конечно. на них хоть гарантию дают какую нить?

(105) год. и по гарантии меняют.

(76) Вообще-то зависит не только от количества пользователей, но и от того, что это за пользователи. Одного (38) достаточно, чтобы база встала колом.

(99) (100) с чего Вы взяли что данные и система на одном контроллере?
система на встроеном в материнскую плату контроллере, а массив на внешнем контроллере... вот и в чём связь если системный диск стоит ССД а база на другом контроллере на HDD.. пока систему не запустил с обычных HDD... тормоза в 1С не прекратились...может терминальные сессии как то ССД системку грузят....

(108) конечно. %TEMP% - его вообще лучше на рамдрайв сделать, если рамы много, гига 4-6

(109) вечерком перекину темп на SSD

(110) встанет колом, перекинь на рамдрайв лучше

(111) там операций записи столько же, сколько чтения - для ССД очень плохой вариант - и с точки зрения живучести, и с точки зрения производительности. еще и система трим не поддерживает, наверное

(102) всё же думаете не стоит держать базу на ССД?