Вход | Регистрация


1С:Предприятие ::

Метки: 

8.3х64 MSSQL12, 40 баз, железо 10ти летней давности, всё тупит и падает в recovery, как жить дальше

Я
   Товарищ без штанов
 
07.01.18 - 11:12
День добрый.
Вопрос я думаю уже платиновый, но вразумительного ответа так и не нашел.
Есть сервер. Старенький, но живой. На борту Xeon E1230, 16гб оперативки DDR3 с ECC. Мать интел, на ней есть софт рейд. Собственно еще давно сделал там 1 диск не в рейде под операционку и софт, 2 диска в зеркале под базы, 1 диск под обменник. Диски в рейде свежие WD Blue Sata 3, висят на 2х единственных 6гб портах. Диски же под хлам и систему Sata 2.
Изначально баз было штук 40, фирма оказывает консалтинговые услуги. Все базы были файловыми. В принципе пока была версия 8.2, все было суперотлично, потом с переходом на 8.3 все становилось хуже с каждым обновлением. И вот момент настал, в районе марта прошлого года, после обновлений базы стали открываться по 5 минут. Не помогало уже ничего, ни очистка кэша, ни пересчет индексов. И да, сами диски дефрагментируются по расписанию, так что это тоже не причина. Проверял скорость винтов - все гуд, в пределах нормы.
Собственно погрузившись в темные закоулки гугла, стало понятно что пришло время переходить на SQL. Прикупили MSSQL Server 12й и x64 сервер 1с. Настроил по гайдам sql и кластер, конвертировал базы, сама база на рейде, логи на диске с хламом. Отдал под sql 6гб оперативки, 9 под 1с, и гиг оставил ос. Регламентированные задачи настроил тоже.
После этих операций базы стали открываться буквально за минуту-полторы, никаких проблем.
Проблема же появилась буквально в октябре, после очередного обновления. Базы стали открываться все медленнее. Перерыл гугл, даже примерно не нашел ответа. В декабре же опять после обновления началась дичь. Во первых сервер сам начал работать натужнее, просто все даже открывается медленнее. В журнале sql сервера кучи ошибок выполнения регламентированных задач, при чем в тексте ошибки просто написано что вот на той базе споткнулся, просто потому-что. Периодически базы падают в режим восстановления и висят так по 5-10 минут. Ну и у пользователей соответственно вываливается что база не обнаружена, ошибка шаред мемори на натив клиенте sql, при этом нажав 3-4 раза повторить, все открывается, и работает без нареканий.
За праздники отрезервировал базы отдельно, в новый архив акрониса, дабы не путался с боевым. Попробовал пересоздать/переподключить базы, эффекта не дало. Но заметил такую вещь, когда кластер 1с отключен, все базы резко перестают уходить в восстановление, и работают весьма штатно, сервер вновь шустро бегает. Запускаю службу обратно, и все опять укатывается в болото.
У меня всего 3 варианта:
1. Обычные винты не вытягивают нагрузку.
2. Мало оперативной памяти.
3. Ошибки в конфигурации сервера.

Нужны ваши советы мудрые.
 
  Рекламное место пустует
   Лефмихалыч
 
1 - 07.01.18 - 11:28
Открывается минуту-полторы - это капец как медленно. Здесь, вероятнее всего, время уходит на поиск ключа защиты броадкастом. Ключи защиты какие? Сколько их?

"Периодически базы падают в режим восстановления" - 1С тут ни при чем.

Нет самого важного - результатов хоть каких-нибудь замеров. У тебя поди все твои 16 гигов забиты под заявязку и процессор занят на 100%, потому и тупит всё.
   Лефмихалыч
 
2 - 07.01.18 - 11:29
постоянный переход баз в рекавери - это беда. Надо выяснять, почему это происходит. Но дело не в 1С.
   Zamestas
 
3 - 07.01.18 - 11:30
(0) WD Blue - выкинуть и никогда не использовать. Или Black или Enterprise.
   PiotrLoginov
 
4 - 07.01.18 - 11:30
>> Проблема же появилась буквально в октябре, после очередного обновления. Базы стали открываться все медленнее

Мне показалось, что единственный способ оценить производительность - замерить скорость открытия интерфейса ПО. Этого недостаточно. Сейчас есть разные способы измерить и протестировать состояние дисков, скорость операций чтения и записи, шустрость оперативки и сети, "настроенность" СУБД, общую (не применительно к конкретным БД) производительность ПАК 1С, состояние тех или иных конкретных баз - апдекс и время, затрачивамое на регламентные операции.

Вот когда все это замеряно и сохранено, а потом после каких-то изменений снова замеряно и сравнено - вот тогда уже можно делать выводы
   PiotrLoginov
 
5 - 07.01.18 - 11:31
(1) опередил
   Лефмихалыч
 
6 - 07.01.18 - 11:54
(4) правильный способ оценивать производительность - эти perfmon.exe и 1совский замер производительности.
Все остальное - пальцем в небо
   PiotrLoginov
 
7 - 07.01.18 - 12:13
(6) категорически не согласен.. и что понимается под "1совский замер"?
но даже если бы так - ТС'у не только с производительностью разбираться надо, например: "В журнале sql сервера кучи ошибок выполнения регламентированных задач"

С каких пор работа с CPU-z и SMART - это пальцем в небо?
   Лефмихалыч
 
8 - 07.01.18 - 12:18
(7) CPU-z и SMART - это не инструменты для замера производительности. Это инструменты для диагностики причин падения этой производительности ПОСЛЕ того, как доказано, что производительность падает по вине CPU или HDD.

1совский замер - это 1совский замер
https://i.imgur.com/3Yfmcmy.png
   Черный маклер
 
9 - 07.01.18 - 12:26
(0) ...фирма оказывает консалтинговые услуги - бухобслуживание ? пользователей 3-5 ?

поставь пару SSD и вернись к файловым базам
   PiotrLoginov
 
10 - 07.01.18 - 12:35
(8) >>ПОСЛЕ того, как доказано, что производительность падает по вине CPU или HDD
 т.е. (a) сначала выносим вердикт и доказываем, что некий код выполняется долго из-за нестабильной итоговой частоты процессора,
 а потом уже (b) лезем в cpu-z для "диагностики причин" этого.

ок. :) интересно узнать. как на этапе (a) определишь, что "виновен" процессор и "докажешь" это без инструментов "контроля максимальной частоты процессора" (цитирую Гилева), т.е. без cpu-z и ему подобных?
 
  Рекламное место пустует
   mingw
 
11 - 07.01.18 - 12:39
(10) Очень просто. Погугли "Xeon E1230". Год выпуска. Сравни с текущим.
   Лефмихалыч
 
12 - 07.01.18 - 12:40
(9) если одновременных пользователей больше пяти, то наступит жопа. Причем - не важно, в одной базе будет 5 пользователей или в пяти - по одному. В итоге общая производительность этих все баз будет стремится к производительности самого медленного клиента. Если сделать из этого писюка терминал, то все будет еще драматичнее.

(10) почитай что-нить про perfmon и анализ производительности виндового сервера
   PiotrLoginov
 
13 - 07.01.18 - 12:40
(11) не, ну это частный случай мы же говорим об общем алгоритме
   mingw
 
14 - 07.01.18 - 12:41
(13) Ок. Общий алгоритм: Железу >5 лет -> на свалку.
   Товарищ без штанов
 
15 - 07.01.18 - 12:44
(1)

Ключ на сервер был просто пин. На клиентах тоже софтовый, на каждой машине свой.

>"Периодически базы падают в режим восстановления" - 1С тут ни при чем.
Но при выключенной службе 1с, режим восстановления не появляется, как и ошибки в регламентированных, все отрабатывается на ура.

>Нет самого важного - результатов хоть каких-нибудь замеров. У тебя поди все твои 16 гигов забиты под заявязку и процессор занят на 100%, потому и тупит всё.
Процессор занят на 20-50% скачками. Но это не показатель что он не используется полностью. Оператива почти всегда гига 4 свободно, пока не открыто баз 5-6 за раз.

(2) Я грешу на винт с логами. Хотя опять таки, смарт в норме, виктория не выявила криминала за 3 прохода, скорость в норме. И плюс, они перестают падать без 1с.

(3) Что есть. Выбирать не приходится.

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

(14) Весьма 1сный подход.
   PiotrLoginov
 
16 - 07.01.18 - 12:44
(14) Иначе (?)

(12) о чем нам спорить? по-моему, речь об дном и том же, только разными средствами. Я не фанат cpu-z. Можно тоже самое посмотреть в системном мониторе
   Товарищ без штанов
 
17 - 07.01.18 - 12:49
Кстати ошибка. Xeon E1230v3
   Черный маклер
 
18 - 07.01.18 - 12:57
(15) попробуй у всех баз выключить регламентные задания
   mingw
 
19 - 07.01.18 - 13:02
(17) Ок. >5 лет && Тормозит? На свалку!
   Товарищ без штанов
 
20 - 07.01.18 - 13:05
(18) это даст я думаю весьма временный прирост. Со временем, без регламентированных задач, база м станет немного совсем худо.
   mingw
 
21 - 07.01.18 - 13:16
(0) Подскажи случаем не терминальный сервер?
Вместо тонких/веб клиентов.
   Товарищ без штанов
 
22 - 07.01.18 - 13:20
(21) не, вся бизнес логика на стороне клиента.
   Товарищ без штанов
 
23 - 07.01.18 - 13:22
и никакой виртуализации
как и rdp
   mingw
 
24 - 07.01.18 - 13:24
Попробуй воткнуть 1 шустрый SSD. Под систему.
   Товарищ без штанов
 
25 - 07.01.18 - 13:27
(24) Нет ssd, и не будет. Денег нет. Я уже писал это выше.
   mingw
 
26 - 07.01.18 - 13:30
(25) Эээ. Нет 5 т.р.? А зарплату хоть платят?
   Товарищ без штанов
 
27 - 07.01.18 - 13:42
(26) Смотрим ссд за 5к в локалсторе. Это OCZ на 240гб. Перенос на ssd только системы - так себе прирост, нужно еще бы и базы туда залить. Смотрим сколько занимают базы с логами - около 180гб, смотрим сколько система с софтом - 50гб. Итого - 10гб остается. Смотрим процент вымирания дисков OCZ - примерно каждый 50й. Как-бы не очень картина, нужно их в зеркало хотя-бы собрать. Итого 10к. Если учесть что фирма далеко не богата, и в прошлом году сократились с 7 сотрудников до 5, и переехали в более дешевый офис, эти 10к мне никто не даст.
Не все живут в Москве. В регионах и 10к деньги, особенно если учесть что сотрудники там максимум 25к получают+премия по выработке там 5-7к.
   mingw
 
28 - 07.01.18 - 13:53
(27) Оставь базы в покое на HDD. Ты систему ограничил 1 гиг рам. Оно свопит.
   jsmith82
 
29 - 07.01.18 - 13:56
Оперативки мало
   jsmith82
 
30 - 07.01.18 - 13:56
можно отключить рег. задания
   jsmith82
 
31 - 07.01.18 - 13:59
(27) Поэтому ты без штанов?
   patya
 
32 - 07.01.18 - 14:13
(27) Вот здесь твоему безштанному коллеге уже рассказали, что с таким бизнесом делать:
https://forum.infostart.ru/forum86/topic184307/
   Lama12
 
33 - 07.01.18 - 14:33
(0) Софтверный рейд. Дальше можно не продолжать.
 
  Рекламное место пустует
   Товарищ без штанов
 
34 - 07.01.18 - 15:34
(29) отдал под 1с 7гб, а под sql 6гб оперативы, загрузка процессора взлетела до 100%
   Alexor
 
35 - 07.01.18 - 19:35
Платформа то хоть какая? Обновлял.

В какой-то летне-осенней 8.3.10 были дикие тормоза при скуле
   Новиков
 
36 - 07.01.18 - 19:59
(0) >>Проверял скорость винтов - все гуд, в пределах нормы.
Цифры какие по mdf и ldf?

>> 16гб 
Зачем при таком объеме ОП ты перевел их в клиент-сервер? Нет денег на апгрейд, тебе какая разница, что будет дальше? Ключевая ошибка в таком паттерне поведения как у тебя, искать в таком унылом не сервере, но компьютере для игры в тетрис, какие-то проблемы с чем? с производительностью - это значит, что контора буквально оплачивает в воздух каждый час твоей работы. Весь этот сервер целиком нужно загнать на авито, выручить какие-то деньги, докупить обычный компьютер на i3 последнего поколения и ВСЕ БУДЕТ БЫСТРЕЕ. Если у них на это нет денег, ты тут причем? Работайте с тем, что есть. В конце концов, все скорее всего навернется, раз ты даже лог уже прочитать не в состоянии и понять, конкретно какая там краснота. Навернутся базы - дальше будет так: контора либо начинает восстанавливать учет, но это для них не реально, либо платят за восстановление, не факт что возможно. Им это нужно рассказать, а не делать ИБД, как ты. С 16 гигами ОП и при этом спрашивать - мудрые советы. Не зависимо не от чего, тут мудрых советов не будет.
   Cyberhawk
 
37 - 07.01.18 - 20:05
Скока очередь к винтам в мониторе ресурсов?
   Dmitry1c
 
38 - 07.01.18 - 20:10
(36) дык видимо по его советам нашли денег на скуль и серверную винду

ну а после... деньги кончились
   Dotoshin
 
39 - 07.01.18 - 20:52
(0) Посмотри на досуге, может натолкнет на какие-то мысли
https://youtu.be/oljKKUJwAUw
   dmtrpv
 
40 - 07.01.18 - 21:06
(38) возникают сомнения,что купили, потому что тот ms sql что там описан плюс серверные лицензии 1с выйдут в астрономическую сумму и контора, которая смогла бы себе это позволить, 10 тыщ на ssd точно бы нашла. Поди проблема, что глючат там все кряки ломалки у топикстартера. Но это так, предположение.
   Cyberhawk
 
41 - 07.01.18 - 21:16
(40) А ты видел чтобы кряки-ломалки "глючили" и в чем это проявлялось?
   Лефмихалыч
 
42 - 07.01.18 - 21:17
(15)>Но при выключенной службе 1с
"после" - не значит "в следствие".
При остановленном rphost'е базы не используются и по этому их состояние и не меняется в консоли скуля. Они в рекавери падают не потому, что их 1С использует, а потому, что их вообще просто кто-то использует.
   dmtrpv
 
43 - 07.01.18 - 21:20
(41) я в них не разбираюсь, но поедполагаю всякие отваливания ключей и что-то такое.
   Лефмихалыч
 
Модератор
44 - 07.01.18 - 21:24
(41) безблагодатная тема
   GreyK
 
45 - 07.01.18 - 22:55
(0) За пару тыщ рубликов куплю твой хлам, мне как раз нужен сервак под эксперименты. Могу тебе взамен отдать пару-тройку компов на 415-465 чипах, на них люди работают и не жалуются. Первым делом снесу ОС и все разделы ЖД напрочь, а потом буду учить его работать как надо.
   Aleksey
 
46 - 08.01.18 - 05:30
(41) Я видел. На последней платформе 8.3.10. Проявлялись что файловые базы через минуту работы вываливалась с ошибкой в структуре (серверная работала без проблема)
Лечилась заменой кряка или установкой ключа. При этом физически с базой ничего не происходило
   Djelf
 
47 - 08.01.18 - 11:58
(34) > отдал под 1с 7гб, а под sql 6гб оперативы, загрузка процессора взлетела до 100%
Загрузка чем? Просто загрузка это сферический конь в вакууме.

Попробуй указать серверу количество ИБ на процесс 1, а соединений побольше. На более тухлом по процессору сервере это помогло, правда все на ssd, хотя и сата2.
   Лефмихалыч
 
48 - 08.01.18 - 12:04
если лошадь сдохла - слезь
   rphosts
 
49 - 08.01.18 - 17:00
(0) люто на такой машине 40баз на 180Г гонять...
А юзеров то сколько?
Зеркало для производительности никаким местом.
> отдал под 1с 7гб, а под sql 6гб оперативы, загрузка процессора взлетела до 100%

6Г для 180Г баз? Да вы издеваетесь!!!
Разумеется будет диск постоянно дёргать и проц уходит в топ.

Из говна не сделать конфетки как ни крути. На вашем-бы месте я:
1.Переустановил ос и весь софт на сервере.
2.Файлопойку в другое место.
3.Добавил рамы хотябы ещё 16Г.
4.Схема электропитания = высокопроизводительная.
5.Раз денег мало один винт(побольше) под ос и базы, второй(поменьше) под журналы, третий (самый дешманский ссд) под темпы.
6.Антивирусы, брэндмауэры и прочее лесом.
7.настроить shared memory.

8.начал бы искать работу.
 
  Рекламное место пустует
   Товарищ без штанов
 
50 - 08.01.18 - 21:47
В общем и целом, я решил проблему.
Первым шагом - грохнул кеш сервера 1с. Базы стали открываться без задержки, но все равно с сообщением о том что база не обнаружена.
Вторым шагом - отключил все базы в sql, грохнул логи, подключил обратно. Все по одной. Сообщение о не существовании базы исчезли.
Но так-то это не решение, а чистой воды везение. Первым делом нужно разжиться ссд, а дальше уже по обстоятельствам.
   Лефмихалыч
 
51 - 08.01.18 - 22:15
(50) оперативой еще разживитесь. Максимально возможным объемом



Список тем форума
  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует