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

ситуация - наблюдаю за загрузкой процессора на сервере и скоростью пересчёта скриптов

обычно загрузка процессора, во время торгов - 20-30% , но иногда бывают моменты - скачет и до 80%, когда был сервер с меньшей оперативкой и производительностью скачки доходили до максимума

в следствие этого увеличивается скорость пересчёта скриптов


вопрос-
1.из-за чего такое может происходить?
2.как этого избежать?
3.влияет ли на это брокер? (почему-то закралась такая мысль, что если перейти на плазу, то может быть эти проблемы могут решиться...)

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

загрузку процессора надо смотреть не ВООБЩЕ а только ту что ест ТСЛАб. То что ест не он, к нему не относится. Там может быть куча разных вариаций почему система вдруг сожрала пол процессора. Например решила поискать апдейты винды в тырнете. Стабильно одно ядро под это откусывает в такие моменты.

Раз процессор угружен, работа тслаба замедляется. Это логично. Брокер врядли повлияет на загрузку вашего процессора.

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

работает всего 2 приложения
тслаб и системный мониторинг

фото по процессам прилагаю

поидее же технология Xen применяется, вроде ж недолжны проблемы на одном сервере сказаться на другом?

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

а зачем на сервер аваст поставил?
и не ту картинку дал, нужна загрузка памяти и цп

аваст удалил, как-то ставил триальную версию, так и осталась висеть...

фотку прикрепляю

бывает что загрузка всего 15% стабильно и длительное время...


вот мне и интересно, от чего сегодня одна загрузка, а завтра - другая?

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

Поэтому первое - процессор на 80% потребляет тслаб? Или другой процесс?
Если ТСЛаб то нет ли скриптов работающих по тикам? Пок/прод? Не наблюдается ли на рынке в этот момент сильная движуха? По опыту некоторых терминалов знаю что при движухе винт может начать хрустеть куда как быстрее

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

спасибо! понаблюдаю за процессами в моменте.

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

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

собственно и вопрос - почему они возникают?

оперативка не скачет, т.е. если было использовано 40%, то свободно - 60%, загрузка процессора скачет...

Движуха на рынке влечет за собой бОльший объем данных поступающих в терминал. Терминал начинает в поте кода своего обрабатывать сей объем данных. Если в терминале есть кэширование данных, то это еще и на винт нагрузочка. А ТСЛаб кэширует тики. + еще стаканы пишете . Если конечно брокер мертвый и апдейты приходят редко, тогда плакать не стоит. На плазе апдейты могут летать очень часто. Вообще там срезы раз в 30 мс летают. Отсюда за секунду 30 апдейтов стакана вполне реально получить.

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

это дааа...

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

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

спасибо, понаблюдаю

результаты наблюдения на фото

если тслаб съедает 30%, то и системные прерывания возрастают до 20%

а если тслаб съедает 15%, то и системные прерывания меньше...

можно как нибудь эти системные прерывания уменьшить или вообще исключить?

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

Обычно системные прерывания на высоком уровне говорит о том что хреново дисковая подсистема настроена или иная система ввода вывода. Такое бывает если диски не в DMA режиме например. Это НЕ НОРМАЛЬНО!

Еще системные прерывания бывают от неправильных дров на какое-то из устройств. Например, видеокарта или сетевая.

это тоже устройства ввода вывода. И сетевая и видеокарта. Даже usb контроллер может им быть. Да я наблюдал такое из за хардов и из за сетевой. только на сетевой было под freebsd при высокой пакетной нагрузке, но то было нормально.