Утро доброе..
База упп работает под управлением MsSql и раньше лежала на отдельном 10 рейде состоящим из 4-рех  SAS винчестеров.
сейчас базу переложили на внешнее хранилище MSA-70, где собрали 10 рейд из 8-ми sas винчестеров. Существенного прироста производительности не получили.. По счетчикам производительности, "Среднее время обращения к диску(с)" достигает 200 mc.. , Средняя очередь к диску порой достигает заначения 30
По каким причинам возможны тормаза с файловой системой?? в какую сторону копать??

а на сервере со скулем скока памяти?

32 гига

база порядка 100 гиг

Сеть какая между серваком и SAN'ом? Ее обычно 10 Гбит делают, чтобы получить приемлимую производительность...

(4) msa 70  и сервер соединены специальным шлейфом, не помню как его точное название..

(0) ахринеть...

Нафига делать единую помойку??? У вас дикая очередь к диску и вместо того, что бы разносить операции по РАЗНЫМ дискам Вы опять делаете единую помойку только из бОльших дисков...

ЗЫ.. разбей дисковый массив "по умному"...

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

(6) в догонку, база работает в simpl режиме..

(7) пофигу...

файлы БД должны быть на другом девайсе от Лог-файлов и на другом от операционки с их сфоп-файлом

У нас сервер с аналогичными параметрами (32гб озу, для sql 20 гб выделено, raid 10, винтов штук 9 вроде) и аналогичной базой (до 120 гб) справлялся. Очереди не было совсем, но приходилось ночью сервер 1С перезапускать, иначе блокировки были на след.день. Правда, база - почти самописка.

(10) баха и у нас справляется, но при большой активности пользователей конфликты блокировок часто появляются..

я по рабочим обстоятельствам уйду из ветки на 20-30 минут.

я вернулся.

(12) и-и-и... расскажешь что нового? :-)

Проблему производительности сам объяснил в (0) ""Среднее время обращения к диску(с)" достигает 200 mc.. , Средняя очередь к диску порой достигает значения 30 "(с)

Так что хочешь услышать? Что существует универсальная таблетка счастья которую "глотнул" и вот оно счастье???


ЗЫ.. кстати про очередь к тому же CPU не сказал не слова, какова скорость страничного обмена - тоже.. Типа тут все Кашпировские и нужную инфу получат сами через телекинез. Да? :-)

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

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

(0) А вы эти данные (очередь, время доступа) получили в операционке или средставми мониторинга СХД (вообще, есть такие?)? Если в операционке показывает большие значения, а на СХД все ок - скорее всего виноват тот самый "специальный шлейф".

(16) данные получил из системного монитора Операционной системы win2008

Я помню читал у 10 рэйда производительность растет не линейно с ростом числа дисков, оптимальный рэйд был из 6 дисков вроде. А время доступа это из за внешнего хранилища организуйте лучше через шлейф sas напрямую. Для SQL  включите сжатие таблиц http://reznik.uneta.com.ua/post/2010/07/15/sql-server-2008-szatie-dannih.aspx

(18) уже изучаю..

(18) вроде и красиво написано, но как-то неубедительно.. от компрессии пока воздержсь..

(14) индексирование диска (на уровне виндов) - включено?

да, включено

(14)[очередь в основном выстраивается на чтение]
может при переходе на внешнее хранилище забыли регламентные работы произвести и индексы остались старыми ?

(23) индексы остались старые, есть регламентное задание, которое в зависимости от процента фрагментации делает переиндексацию..

(20) Попробуй тестовую базу сожми размер меньше меньше дисковых операций выше производительность

(24) проделай все регламентные операции, включая очистку процедурного кэша

(25) попробую, но уже как последний вариант..

(26) в ночь запущу полную инедексацию... а кэш очищается регулярно

(21) Убей :-)

Индексирование на уровне виндов только замедляет работу, а пользы - ноль (ведь по данному диску ты же ведь не ищешь файлы интерактивно)


(28( полная реиндексация средствами 1С только "разбухает" базу...

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

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

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

(31) Заведи подобную ветку на: http://3nity.ru

Вклчил показатель "Контекстных переключений/с"  и запустил переиндексацию средствами sql
данный показатель среднее занчение показывает в районе 20000, а максимальное в пределах 93000
если основываться на ссылку http://www.oszone.net/5755/SQL_Server
показатель не должен превышать 10000.  это наверное от того что индексация запущена.

(31) сегодня рабочий день уже кончился.. завтра почитаю твою ссылук на форму. Спасибо!

(33) ссылук=  ссылку )))

Делаешь диски:
1 Raid 10 из 4 дисков для mdf
2 Raid 1 для ldf
3 Raid 1 для Tempdb.mdf

(35) тогда уж рэйд 0 для некритичных данных

(35) не-а... не правильно :-)

Делаешь диски:
1 самостоятельный диск для системного диска (он меняется слабо, поэтому просто регулярно бэкапируешь и если чЁ восстанавливаешь с копии)
2 Raid 1 для mdf
3 Raid 1 для ldf
4 самостоятельный диск для Tempdb.mdf - тмп нафик не нужна устойчивость
5 самостоятельный диск для файла страничного обмена - ему нафик не нужна отказоустойчивость

(37) 1 диск не нужен - у (0) полка.

(37) (35) Красиво написали, только помимо очереди на чтение после такого еще и очередь на запись появится.

(37)Страничный обмен вроде бы не должен при большой памяти.

(39) Если ldf на отдельном диске и mdf может быстро записывать, то вроде бы не должно?

(41) у автора 10-й рейд из 8-ми винчестеров. То есть при записи у нас задействованы 4 диска паралельно. Все что предложено ниже будет гораздо хуже. Причем и для чтения и для записи.
Советы размещать все на отдельных дисках появились когда уровни рейдов ограничивались нулевым и первым, а их до сих пор можно встретить где угодно.

На мой взгляд,  RAID-10 оптимален для некрупных систем, и рейд-контроллер гораздо лучше вас определит приоритеты и очередность  запросов к дисковой подсистеме.
Надо анализировать чем вызвана проблема. По трассировке получить запрос "вытаскивающий" такой объем данных, который тормозит всю дисковую подсистему.

познавательная статья http://forum.ixbt.com/topic.cgi?id=66:7234
а возможны ли большие очереди на чтение из-за того, что я сделал размер страйпа 64к, а размер кластера файловой системы 8к?

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

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

ЗЫ.. "Скорость эскадры определяется скоростью самого медленного коробля ордера" (с) адмирал Макаров

(40) ну-у-у.. батенька.. это же азы сисадминства - "страничный обмен есть всегда" (если его нет - срочно к доктору), но этот обмен не должен быть чрезмерным (когда для доступа к ресурсам одна задача постоянно выкидывает в своп иную задачу). А Сиквел по определению любит ОЗУ покушать (если он правильно настроен)

Все вопросы производительности временно снимаются...
пришло время обновить упп 1.2.39 до последней 1.3

(8) У нас тоже простая схема восстановления. А переход на полную как-то влияет на производительность базы? (Если стараться бэкапить журнал транзакций в нерабочее время: утром - в обед - вечером)

(45) А платформа 1С какая?

(46) "А переход на полную как-то влияет на производительность базы?"

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

(48) на УПП не влияет,
на ней 90% жрёт rphost

и даже перенос сиквела на RAM диски ускоряет на проценты

(49) если на УПП работают макс "три калеки" - то тогда, да.. влияет весьма слабо (но тогда и цимуса переводить в фулл моду нет никакого). А вот если УПП работает "по-взрослому" - то ой как влияет...

(47) платформа пока 8.1

(51) и как же ты на 1.3 собрался перейти ?

(52) через адские мучения, потому как дописок много.., порядок такой..
1 - устанавливаем сервер 1с под 8.2 и  стартуем его
2 - конвертируем конфигурацию 1.2 под платформу 8.2
3 - качаем обновления 1.3.13.1 по 1.3.18.1  и поэтапно ставим каждое обновление.
вот примерно так...

(53) А с чего там "дописок много.."
Неужели, крути УПП не хватает полностью?

(54) странный вопрос...!!!!
Если бы не было доработок, пустили бы весь наш отдел  по миру... и пришлось бы идти в грузчики...
А так благодаря дработкам, в свелом офисе сижу. )))

(54) А если серьезно, то "тюниг" конфигурации под нужны предприятия, обычная работа ИТ отдела.

(56)Много пришлось "тюнинговать"?

(48) "А сам подумай.. если после перехода на "полную" сиквел начнёт ещё писать в лог-файл все изменения с базой..."
ms sql пишет в лог и при полной и при простой модели восстановления.

(53)Нет, я об этом:
Важная информация
-----------------------------------------------------------------
Внимание!
Текущий релиз конфигурации "Управление производственным
предприятием" предназначен для использования с версией системы
1С:Предприятие 8 не ниже 8.2.14!
-----------------------------------------------------------------

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

(60) не совсем понятно что вы хотели сказать. SQL Server так себя будет вести и в простой, и в полной модели восстановления. Где тут резерв производительности?
(58) прав. Разница в том что будет писАться в лог будет только на части регламентных операций, обычно проходящих в то время когда пользователи не работают.

(60) я и говорю - в лог пишется при любой модели.
а чекпоинт никакого отношения к модели восстановления не имеет.

а по теме:
я бы начал с переиндексации
и с тестов типа sqlio для определения уровня проблемы: либо физический, либо БД

(59) установил 8.2.14.537 да и делаю обновление тестовой базы...
А что, есть то чего я не знаю про 8.2.14 ????  
Скажи, что тебя тревожит  в (59)

(63) переиндексация прошла...
всем остальным займусь после перехода на 8.2

(61) Я не утверждаю, спрашиваю... сомнения были при переходе на простую схему, не снизит ли это производительность в целом? Лог-файл резко растет при большой нагрузке, когда не успевает сбрасывать транзакции в базу. Поэтому полагал, что лог-файл (возможность его роста) некий резерв производительности. При переходе на простую схему особенного снижения не замечено (субъективно, замеров не делал). А у вас были замеры?

(64) На 8.2 переходили в конце 2010 в ред. 1.2 (чтобы на 1.3 перейти) - лучше не стало (скорее наоборот)! А сравнить 8.1/1.2 с последними релизами 8.2/1.3 на одном железе не было возможности... оправдалось?
Вряд ли, у нас в ТС никто не работает, УПП в целом остается обычным приложением, использует режим совместимости с 8.2, т.е. по-прежнему остается 8.1. Может на УПП2.0 8.2 проявит свои преимущества!?

"При переходе на простую схему особенного снижения не замечено (субъективно, замеров не делал). А у вас были замеры?"

Это из серии - "Ни когда не мыл руки перед едой, недавно стал мыть. Субъективные наблюдения - здоровья заметно не прибавилось. Проводили ли Вы замеры, насколько от мытья рук прибавляется здоровье" :-)))

(0) Если увеличении количества дисков не добавило производительности,
может быть стоит поменять контроллер?

(69) Обновление оборудования планируется в следующм году... контроллер уже заложен в план обновления..

(70) Все эти полки, лезвия, рейд-массивы... для меня темный лес, но ни слова о виртуализации и ОС. Собрались с 2008R2 переходить 2003x64, говорят  УПП на ней лучше работает!?

да, а для УТ и БП лучше ХР со 2м сервис паком

(67). "УПП в целом остается обычным приложением, использует режим совместимости с 8.2, т.е. по-прежнему остается 8.1". Неправда ваша. УПП редакции 1.3 работает на 8.2 штатно, без режима совместимости. Более того, она уже на управляемых блокировках.

(73) т.е. не переходить на 2003х64, со временем 8.2 научится использовать новые возможности 2008R2?

В УПП больше всего ресурсов потребляет SQL. Как-то нельзя его поставить минуя виртуализацию, при этом часть сервера оставить под ВМ?

(75) нет,
да, ни кто не ставит сервер 1С и сиквел на один хост

(74). Понятия не имею. Я писал о работе конкретной конфигурации на конкретной платформе. И вообще сильно сомневаюсь, что версия ОС каким-либо образом влияет на производительность.

(74)[со временем 8.2 научится использовать новые возможности 2008R2]
1C работает с СУБД через ADODB
1С не использует и не будет использовать напрямую новые возможности СУБД

(76) Вроде так и есть, поднято несколько виртуальных машин: сервер 1С, SQL-сервер, терминал... и т.д., а железо (серверная стойка) все равно одно!

(76) хотел узнать, как люди делают...?

(79) если сервер хилый не фиг виртуализировать,
если мощный - то в чем проблема ?

Держи в курсе

(79) Общался с техническими специалистами представительства microsoft, так вот, они сказали, что при виртуализации sql сервера, производительность его падает однозначно.

Тогда повторюсь (75), или приговор (76) обжалованию не подлежит?

(84) в (75) написано "Часть сервера оставить под ВМ", не въезжаю, что значить часть сервера??? какую часть???  
Вроде как SQL  всегда съедал много ресурсов и не важно упп это или Бухгалтерия..
Сиквел и сервер 1с очень дружно могут работать на одном хосте. Увеличивается скорость обмена данными между сервером 1с и sql сервером. Иногда это даже выгоднее, чем разносить на разные хосты.  Все зависит от оборудования и количества активных пользователей ...
Требования к оборудованию есть на сайте 1с.

(76) почему? Если сервер с хорошим заделом, то в чем проблема? Серверу 1с нах не критична дисковая подсистема, а проц с рамой не проблема (опять же оперативы ему столько не надо как СКЛю). Основной упор на процессорное время, но если на сервере 12 ядер (без HT), то в чем проблема?

(85) Честно говоря, сам не въезжаю, что есть полка, что есть лезвие... одна серверная стойка на всю компанию, на которой куча разных ВМ, в том числе не касаемо1С. Похоже, виртуализацию не обойти?

(84) чё за херня

(76) К слову бывают специфические ситуации когда сервер приложений и SQL сервер имеет смысл ставить на один сервер. За счет отсутсвия межсетевого взаимодействия(отклик сети важен а не трафик) работать такая связка может лучше. Актуально для большого количеста небольших SQL запросов. Но таких случаев единицы.

(0) Почитай сначала немного теории, не с того начинаешь.

(90) есть конкретные ссылки на теорию?

(89) конечно бывают
есть даже ряд ошибок 1С, которые лечатся только объединением на одном хосте