Неведомая ерунда с сервером предприятия

Форум Администрирование Общие вопросы администрирования (Admin)

1. noxxx 09.10.15 11:39 Сейчас в теме

Имеется сервер предприятия 8.3.6.1999, на нем происходит следующее.

В какой-то момент один из rphost.exe начинает дико писать во временный файл. Пишет до тех пор, пока не закончится 120 Гб свободного места на диске, и затем всё умирает. Но не падает, а просто перестает работать для новых подключений. Какое-то время те кто работал в 1С еще работают, но потом всё перестает работать и у них.

Единственный способ завести всё обратно - остановить сервер предприятия, потом убить зависшие rphost.exe и сопутствующие процессы, удалить кеш сервера и запустить заново.

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

Потом всё работает до очередного случая жора места.

Закономерности пока не наблюдается, т.к. дни и время возникновения проблем разное, базы, которым принадлежат процессы, пишущие огромные файлы, разные.

Обращаюсь к коллективному разуму: куда копнуть?

По теме из базы знаний

Ответы

Подписаться на ответы Инфостарт бот

Свернуть все

2. juzz 09.10.15 12:30 Сейчас в теме

(1)фоновые задания смотрели?

3. noxxx 09.10.15 12:38 Сейчас в теме

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

4. juzz 09.10.15 12:43 Сейчас в теме

(3) А какие расширения у временных файлов?

6. noxxx 09.10.15 12:55 Сейчас в теме

(4) juzz, расширение tmp. В последний раз файл назывался v8_AC10_291e.tmp

8. juzz 09.10.15 13:09 Сейчас в теме

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

9. juzz 09.10.15 13:20 Сейчас в теме

(8) В догонку, посмотрите что во время роста пишется в журнал регистрации.

12. noxxx 09.10.15 13:31 Сейчас в теме

(9) juzz, в журнале регистрации - обычная работа пользователей и фоновые задания, ничего необычного.

10. noxxx 09.10.15 13:23 Сейчас в теме

(8) juzz, одна база 700 Гб, другая 200. Поднимутся?
(9) juzz, мысль, пойду смотреть журнал.

11. juzz 09.10.15 13:28 Сейчас в теме

(10) ГБ??? ну хз

13. noxxx 09.10.15 13:32 Сейчас в теме

(11) juzz, да, именно ГБ :)

14. juzz 09.10.15 13:39 Сейчас в теме

(13) А у sql места для роста хватает? И сколько у sql параметр авторасширение стоит? Пришел к выводу что чем больше авторасширение лога и базы (в разумных пределах) тем меньше тормозов.

15. noxxx 09.10.15 13:41 Сейчас в теме

(14) juzz, так SQL эта тема не затрагивает. Всё падает на сервере предприятия. На SQL места дофига, авторасширение стоит, место не заканчивается.

5. ipoloskov 164 09.10.15 12:54 Сейчас в теме

Помещение чего-то огромного во временное хранилище, не?

7. noxxx 09.10.15 12:57 Сейчас в теме

(5) ipoloskov, у нас такому вроде бы негде взяться. По крайней мере 120 Гб данных во временное хранилище - вообще не могу предположить что это может быть.

16. ipoloskov 164 09.10.15 13:42 Сейчас в теме

Блокировки управляемые?

17. noxxx 09.10.15 13:48 Сейчас в теме

(16) ipoloskov, да.

18. noxxx 09.10.15 14:11 Сейчас в теме

ИМХО тему перенесли не туда куда надо. К БД это не имеет отношения.

19. ipoloskov 164 09.10.15 14:12 Сейчас в теме

Вот здесь что-то похожее обсуждается
http://www.forum.mista.ru/topic.php?id=595203
Мне кажется, дело в этом. Гигантская выборка (через кривой запрос, возвращающий декартово произведение, например) - и готово.

20. noxxx 09.10.15 14:27 Сейчас в теме

(19) ipoloskov, еще бы знать каким образом выловить эту гигантскую выборку ... Или хотя бы определить сеанс, в котором это происходит.

21. ipoloskov 164 09.10.15 14:32 Сейчас в теме

(20) noxxx, техжурналом. События SDBL и DBMSSQL с планом запроса. Фильтр по длительности.

22. noxxx 09.10.15 14:50 Сейчас в теме

(21) ipoloskov, спасибо, попробуем отловить. Как будет информация - отпишусь.

24. noxxx 09.10.15 18:25 Сейчас в теме

(21) ipoloskov, скажите, а где почитать о том как этот ТЖ анализировать?

23. user_2010 943 09.10.15 15:29 Сейчас в теме

на сервере СКЛ, кажется, есть трассировка - ее нужно включить и там можно посмотреть кто и какой запрос выполняет... как-то давно решали подобную проблему...

Оставьте свое сообщение

E-mail: