Pull to refresh

Comments 6

Не впечатлило.
Может потому что, наступал на такие грабли, и могу привести еще несколько, которые встречались в практике. Так как пользователи при любой проблеме с CRM / СЭД обращаются к нам, а причиной может оказаться все что угодно.
Например: смена DNS-серверов, деградация СХД, кто-то в циске покопался, безопасники криво DLP внедрили, у пользователей в кабинете хаб умер, винда обновилась на серваке, сервер заражен вирусом, кто-то циску обесточил.
Из последнего: на УЦ сдохла одна из сетевых плат — стали пропадать пакеты, из-за чего у пользователей стали очень долго подписываться документы. Как мы это выясняли — долгая история — пакеты начинали теряться при определенной нагрузке. Три дня прощупывали каждый промежуточный узел.
В общем, скучать не приходится.

UPD вспомнил еще:
— села батарейка на биосе, а NTP не был выставлен, после перезагрузки сервера — непонятные ошибки в системе;
— на бэкап-сервере, после смены DNS, решили забить параметры сети вручную. Да то ли опечатались, то ли настройщик по памяти забивал — указали неверный шлюз. Из-за чего на нем пропускная способность сети сильно упала — на порядок. Бэкапирование не завершалось за сутки. Нервных клеток убили несчитано…
Хотя казалось бы причем здесь поддержка СЭД…
Так как пользователи при любой проблеме с CRM / СЭД обращаются к нам, а причиной может оказаться все что угодно.

Дадададада… все так =(
Спасибо за интересные кейсы! Жму вашу руку
UPD вспомнил еще:
— села батарейка на биосе, а NTP не был выставлен, после перезагрузки сервера — непонятные ошибки в системе;
— на бэкап-сервере, после смены DNS, решили забить параметры сети вручную. Да то ли опечатались, то ли настройщик по памяти забивал — указали неверный шлюз. Из-за чего на нем пропускная способность сети сильно упала — на порядок. Бэкапирование не завершалось за сутки. Нервных клеток убили несчитано…
Хотя казалось бы причем здесь поддержка СЭД…


Тут уже, конечно, частные случаи. Т.е. с антивирусом мы сталкивались уже не раз, а сетевые настройки слишком уж разнообразны — всего не описать.
Но все равно спасибо вам, что поделились своим опытом!
Загрузку процессора и памяти посмотрели. Молодцы! А почему про глубину очереди чтения записи (queue depth) СХД или сервера ничего не написали? Забыли?
Метрика выражается целым числом и для оптимально загруженной системы рассчитывается по формуле:
Data Queue = 2 + <количество шпинделей жёстких дисков RAID-массива>.
Т.е. если глубина равна 10 или больше, а у вас, например, всего 4 диска (шпинделя) — есть повод задуматься об оптимизации, а если больше 50 — у вас проблема.

Достать показатель проще всего через оснастку монитора производительности (Performance Monitor — Физические носители — актуальная длина очереди). Через Task Manager такое не видно.
Юра, привет тебе, привет! :))
Я менеджер, я имею право забыть =)
Да и суть-то проблем была в ином, но совет тут прикопаем — вдруг кому поможет ;)
Да, привет. Безусловно, я же без претензий. Воспользовался случаем напомнить про эту «древнюю» метрику ;)
По моему опыту 80 процентов тормозов любого компьютера, от ноутбука до сервера, связано с дисковой подсистемой, как самой медленной. SSD эту проблему частично решают.
В общем — «прикопали» этот лайфхак (и можно ещё гвоздиком вверх в правом углу приколотить :))
Sign up to leave a comment.