EM
дело не в месте на диске,а в активности чтения-записи
Size: a a a
2020 December 21
EM
Как я понял такое выскакивает когда пошёл прирост событий с 200 до 1200 после перезагрузки
что именно перезагружали?
🎅L
что именно перезагружали?
Это не стенд а железо
🎅L
Её перезагружал
EM
видимо, скопились очереди событий на обработку в SIEM
EM
пока стенд был не доступен
К
Как я понял такое выскакивает когда пошёл прирост событий с 200 до 1200 после перезагрузки
Ну логично, количество iops выросло, разгребая очередь, скопившуюся пока перезагрузка была. Об этом и сигнал.
EM
какое-то время будет разгребать, пока не догонит текущий входящий поток
🎅L
Ну логично, количество iops выросло, разгребая очередь, скопившуюся пока перезагрузка была. Об этом и сигнал.
Фу.. я думал Рождество испорчено )))
🎅L
Спасибо))
2020 December 22
6
Ну логично, количество iops выросло, разгребая очередь, скопившуюся пока перезагрузка была. Об этом и сигнал.
не iops, а iowait
6
последнее может быть факапом не только диска если что
RS
последнее может быть факапом не только диска если что
Может. Но что это сильно меняет в плане реакции на сообщение?
6
Может. Но что это сильно меняет в плане реакции на сообщение?
В целом повод перетряхнуть сервак
6
может там памяти под кэши не хватает например
6
и на диски идет мелкотня без нормальнго выравнивания
6
или массив мрет - iops не высокий, а вот очереди да
6
хотя да, соврал, все еще факап дисков
PG
Всем привет. На борту сием в конфигурации для высоконагруженных систем. Есть ли возможность найти ненормализованные события с помощью утилиты export_data? Или сырые события совсем не сохраняются?
G
Если в storage опция highload включена, то не сохраняется