Раз в сутки система аномально нагружается на 2-4 часа, что это может быть.
В течение месяца, почти каждые сутки, в разные периоды времени, но часто под утро, система аномально нагружается.
Хостер сказал, что нагрузка создает база данных
Также сказал что то, что показывает панель более 100% нагрузки на процессор, это какой-то баг, такого быть не может.
Повысили тариф на сервере, но это глобально не помогло.
Система в этот период очень тормозит, но работает.
Что это может быть (думали что это может быть розетка обновляет свои справочники, выключили автоматизацию в справочниках + выключили обновление категорий розетка, но ничего не помогло) ?
Оригинальный вопрос доступен на версии: ua
Хостер сказал, что нагрузка создает база данных
Также сказал что то, что показывает панель более 100% нагрузки на процессор, это какой-то баг, такого быть не может.
Повысили тариф на сервере, но это глобально не помогло.
Система в этот период очень тормозит, но работает.
Что это может быть (думали что это может быть розетка обновляет свои справочники, выключили автоматизацию в справочниках + выключили обновление категорий розетка, но ничего не помогло) ?
Ответы:
Добрый день.
1. Нагрузка на cpu может быть больше 100%. Это означает что задач которые нужно выполнить в секунду на X% больше чем процессор может выполнить. Например, если процессор на сервере может выполнить 1000 задач в секунду, а в очереди 1500 то у вас будет нагрузка на cpu 150% в этот момент. Это если прям сильно-сильно упростить.
2. Скорее всего в это время на сервере запускается какая то ресурсоемкая задача. Если у вас версия продукта - os, мы можем произвести анализ нагрузки в указанное время и дать советы как с этим бороться, это займет около 3ч доработки.
1. Нагрузка на cpu может быть больше 100%. Это означает что задач которые нужно выполнить в секунду на X% больше чем процессор может выполнить. Например, если процессор на сервере может выполнить 1000 задач в секунду, а в очереди 1500 то у вас будет нагрузка на cpu 150% в этот момент. Это если прям сильно-сильно упростить.
2. Скорее всего в это время на сервере запускается какая то ресурсоемкая задача. Если у вас версия продукта - os, мы можем произвести анализ нагрузки в указанное время и дать советы как с этим бороться, это займет около 3ч доработки.
27.02.2023, 13:15
1. А как-то можно хотя бы теоретически понять, что это может быть при задании (если таких явных, сложных не выставлялось), то есть есть какие-то такие задачи, которые регулярно система раз в сутки выполняет, то есть какие-то системные?
2. Если на сервере через команду TOP показываю что процессор нагружает база данных, можно как-то понять что это может быть (какая задача или с какой таблицей БД работает процессор) ?
2. Если на сервере через команду TOP показываю что процессор нагружает база данных, можно как-то понять что это может быть (какая задача или с какой таблицей БД работает процессор) ?
27.02.2023, 13:27
Оригинальный комментарий доступен на версии: ua
Юля писал/а:
А как-то можно хотя бы теоретически понять, что это может быть за задачи (если таких явных, сложных не выставлялось), то есть есть такие задачи, которые регулярно система раз в сутки выполняет, то есть какие-то системные?
У системы нет по-умолчанию сложных процессов, которые так грузят систему, есть задания по переносу задач, трекинку ТТН и другие задачи раз в день/час, но они не могут так нагружать процессор.
Юля писал/а:
2. Если на сервере через команду TOP показываю что процессор нагружает база данных, можно как-то понять что это может быть (какая задача или с какой таблицей БД работает процессор) ?
да, нужно в тот же момент смотреть какие тяжелые запросы висят в базу данных, по ним можно понять какой модуль их делает и уже двигаться дальше.
27.02.2023, 13:29
Оригинальный комментарий доступен на версии: ua
.dev
OneBox production писал/а:
да, нужно в тот же момент смотреть какие тяжелые запросы висят в базу данных, по ним можно понять какой модуль их делает и уже двигаться дальше.
А де можна подивитись ці "важкі запити" ?
27.02.2023, 13:41
в самой базе данных в момент нагрузки, в логах тяжелых запросов по базе дынных. К сожалению более конкретно я вам сказать не могу так как не занимаюсь обучением администрирования баз данных и отлова причин нагрузки.
27.02.2023, 13:44
1. А это нормально (согласно скрину) увеличивающаяся нагрузка только на процессор, а например оперативка не увеличивается ?
2. Подобную нагрузку могут давать какие-то "поисковые работы гугл" или что-то подобное?
2. Подобную нагрузку могут давать какие-то "поисковые работы гугл" или что-то подобное?
27.02.2023, 15:19
Оригинальный комментарий доступен на версии: ua
1. вполне
2. Если у вас есть сайт, то да - гугл может индексировать его.
2. Если у вас есть сайт, то да - гугл может индексировать его.
27.02.2023, 15:53
так же вас могут "парсить" какие то другие сервисы.
27.02.2023, 15:53
Прилагаю статистику по phpMyAdmin
Согласно статистике 3 275 000 запросов select в час
То есть получается что 3 275 000/60 = 54 583 (в минуту) / 60 = 909 (в секунду)
Выходит, что имеет 1000 запросов в секунду
Как-то как многовато
Согласно статистике 3 275 000 запросов select в час
То есть получается что 3 275 000/60 = 54 583 (в минуту) / 60 = 909 (в секунду)
Выходит, что имеет 1000 запросов в секунду
Как-то как многовато
06.03.2023, 10:23
Оригинальный комментарий доступен на версии: ua
Юля писал/а:
Якось наче забагато
смотря с чем сравнивать. Все зависит от сложности запросов, например мой пк делает 100 000 записей в базу данных за 10 секунд и при этом грузит ядра менее чем на 15%. Т.е. 10 000 записей в секунду. Чтения при этом в несколько раз проще чем записи.
Если для вашего сервера это проблема, я могу решить её только в случае если у вас os. К сожалению ничего сделать с кодом на mvp я не могу, эта версия продукта не поддерживается. Вы можете сами отдебажить сложные запросы, найти их и переписать или сделать любую другую оптимизацию вашего сервера. Начать можно с отключения действий "раз в час" например, возможно грузит пересчет цен или что то еще. Так же попробуйте посмотреть в лог запросов к серверу в nginx, возможно там будут запросы на страницы вашего сайта и кто-то Вас парсит, так вы сможете прибанить его ip например. Вобщем тут тысячи вариантов того, почему ваш сервер тупит и все они решаемы.
06.03.2023, 20:47
.dev
OneBox production писал/а:
мой пк делает 100 000 записей в базу данных за 10 секунд
Вы пишете о "записях" (т.е. добавлении новой строки в таблицу) это INSERT
А статистика как будто показывает "запросы" то есть количество SELECT в секунду
Это словно немного разные вещи, могли ли Вы подразумевать что у вас 10 000 SELECT в секунду
Просто в нашем случае (активных товаров налицо примерно 3000) непонятно что можно выбирать SELECT-ами столько раз, то есть у нас 3000, а система делает в среднем 1000 запросов в секунду и это в течение 2-4 часов, то есть как-то непонятно что можно парситы из 3000 товаров с помощью 3 275 000 запросов в час, это больше похоже на некую DDoS attack
07.03.2023, 10:44
Оригинальный комментарий доступен на версии: ua
Несколько мониторив видно что периодически возникает какая-либо нагрузка в 3000-4000 запросов в секунду, это при нормальных показателях процессор, похоже что у пики нагрузки эти запросы возникают каждую секунду и затем идет большая нагрузка.
Посмотрев размер таблиц, есть таблица дополнительных полей "shopcustomfield", она имеет примерно 3 100 000 записей и размер 1Гб
Возможно такой показатель таблицы "shopcustomfield" и создает такое количество запросов и такую проблему, это примерно нормальные показатели для этой таблицы ?
Посмотрев размер таблиц, есть таблица дополнительных полей "shopcustomfield", она имеет примерно 3 100 000 записей и размер 1Гб
Возможно такой показатель таблицы "shopcustomfield" и создает такое количество запросов и такую проблему, это примерно нормальные показатели для этой таблицы ?
07.03.2023, 11:04
Оригинальный комментарий доступен на версии: ua
Юля писал/а:
А статистика наче показує "запити" тобто кількість SELECT за секунду
SELECT в большинстве случаев в несколько раз легче по нагрузке для БД чем INSERT, по-этому я привел вам пример именно с INSERT. Т.е. если я выполняю 10к вставок, то с легкостью смогу выполнить столько же чтений.
Юля писал/а:
Можливо такий показник таблиці "shopcustomfield" і створює таку кількість запитів і таку проблему, чи це приблизно нормальні показиники для цієї таблиці ?
это относительно нормальное к-во данных
Я вижу Ваши графики, но к сожалению могу только сказать что они очень красивые, больше в них для меня нет никакой ценной информации. Да, у вас относительно много запросов, которые непонятно кто, когда и с какой целью делает. Решения я писал выше, если у вас os (судя по всему это не так), дайте ссылку на ваш бокс и я Вам помогу. Если у вас mvp - дебаг запросов в бд полностью на Ваших плечах.
07.03.2023, 12:55
.dev
OneBox production писал/а:
SELECT в большинстве случаев в несколько раз легче по нагрузке для БД, чем INSERT, поэтому я привел вам пример именно с INSERT. Есть. если я выполняю 10к вставок, то легко смогу выполнить столько же чтений.
Вы говорите о 10 000 добавленных записей
А статистика показывает 1000 запросов (т.е. например один запрос может выбрать/добавить/обновить 10 000 записей и это уже за суккунду будет 1000*10 000 это же немного разные вещи).
Попробуем сначала пожалуй оптимизировать БД
На базе анализа БД видно, что есть проблемы
Например, в дополнительных полях продуктов процесса есть галочка которую мы используем "Автоматически заполнять с фильтра товара"
Так вот получается у нас например есть 50 дополнительных полей продуктов процесса, которые мы используем в одном из 20 процессов, а в других не используем
Но получается что система на базе этой галочки "Автоматически заполнять с фильтра товара" заполняет поля по всем БП куда добавляются товары и в результате увеличивается количество записей в таблице в разы, то есть вместо 1 записи, их в результате становится 20 (если товар добавили во все 20 БП).
Возможно есть решение как сделать так, чтобы эта галочка "Автоматически заполнять с фильтра товара" срабатывала только на конкретном БП или может есть действие в БП которая будет копировать фильтры товаров в продукты процесса (т.е. обратное действие действия "Добавить фильтра товара с дополнительных полей процесса") или может быть какое-то действие, которое может изымать дополнительные поля продуктов процесса?
07.03.2023, 14:01
Оригинальный комментарий доступен на версии: ua
Юля писал/а:
Ви говорити про 10 000 доданих записів
А статистика показує 1000 запитів (тобто наприклад один запит може вибрати/додати/оновити 10 000 записів і це вже за сукунду буде 1000 * 10 000 це ж трохи різні речі).
Вы не поняли о чём я. Считайте что я Вам ничего не писал про к-во запросов.
Юля писал/а:
Але виходить що система на базі цієї галочи "Автоматично заповнювати з фільтра товару" заповнює поля по всім БП куди додаються товари і як результате збільшується кількість записів в таблиці в рази, тобто замість 1 запису, їх в результаті стає 20 (якщо товар додали у всі 20 БП).
Вы не с того начали. ВЫ НЕ ЗНАЕТЕ КАКИЕ ЗАПРОСЫ ИДУТ В БД. Но при этом начинаете что то предполагать и уменьшать какие то таблицы, в которые возможно вообще не идут запросы. Вам нужно выяснить:
1. Какие запросы
2. Откуда
3. В каком количестве
идут в базу а потом уже решать что с этими запросами делать. Не наоборот. Если у вас нет программиста/системного администратора который может провести этот анализ, можете не тратить своё время, вы ничего не найдете. То что вы начали тыкать в рандомные таблицы и делать какие то предположения может пофиксить проблему а может и нет, попыток "поправить" какие то таблицы у вас около 300 +-, как и к-во таблиц. Вы будете каждую так трогать? А друг все эти 1000 запросов в секунду идут в таблицу novaposhtainvoice и не зависят от к-ва данных там?
07.03.2023, 14:10
.dev
OneBox production писал/а:
Вы не с этого начали. ВЫ НЕ ЗНАЕТЕ КОТОРЫЕ ПРОТИВ ИДУТ В БД. Но при этом начинаете что-то предполагать и уменьшать какие-то таблицы, в которые, возможно, вообще не иду
Спасибо, есть такое, идешь в магазин за хлебом, выходит с пакетом других товаров :)
Попробуем начать с этого.
Подскажете решение по проблеме ниже?
Например, в дополнительных полях продуктов процесса есть галочка которую мы используем "Автоматически заполнять с фильтра товара"
Так вот получается у нас например есть 50 дополнительных полей продуктов процесса, которые мы используем в одном из 20 процессов, а в других не используем
Но получается что система на базе этой галочки "Автоматически заполнять с фильтра товара" заполняет поля по всем БП куда добавляются товары и в результате увеличивается количество записей в таблице в разы, то есть вместо 1 записи, их в результате становится 20 (если товар добавили во все 20 БП).
Возможно есть решение как сделать так, чтобы эта галочка "Автоматически заполнять с фильтра товара" срабатывала только на конкретном БП или может есть действие в БП которая будет копировать фильтры товаров в продукты процесса (т.е. обратное действие действия "Добавить фильтра товара с дополнительных полей процесса") или может быть какое-то действие, которое может изымать дополнительные поля продуктов процесса?
09.03.2023, 14:35
Оригинальный комментарий доступен на версии: ua
к-во select не зависит от к-во значений в shopcustomfield, т.е. вы копаете не туда
09.03.2023, 14:38
.dev
OneBox production писал/а:
к-во select не зависит от к-во значений в shopcustomfield, т.е. вы копаете не туда
Вопрос больше всего не связан с основной проблемой, просто хотелось бы его также решить, потому что он, по сути, влияет на объем БД и как результат на работу сервера в целом (т.е. база растет и как результат для нее нужен лучший сервер )
Можете предложить какое-либо решение для решения описанной проблемы?
09.03.2023, 14:57
Оригинальный комментарий доступен на версии: ua
Юля писал/а:
Можете предложить какое-либо решение для решения описанной проблемы?
если у вас mvp, я не могу дать вам какое-нибудь решение. Если вы перейдете на os, я смогу его предоставить.
09.03.2023, 14:59
Оригинальный комментарий доступен на версии: ua
.dev
OneBox production писал/а:
Если вы перейдете на os, я смогу его предоставить.
Относительно перехода мы сейчас находимся в состоянии принятия решения (есть ряд проблем перехода, в том числе и сайт)
Пока на OS решения также нет, нужно делать доработку?
09.03.2023, 15:47
Оригинальный комментарий доступен на версии: ua
можно будет сделать настройку, чтобы не заполняло значение если его нет в фильтре. Т.е. чтобы не генерило пустые записи, займет пару часов.
09.03.2023, 16:38
.dev
OneBox production писал/а:
можно сделать настройки, чтобы не заполняло значение, если его нет в фильтре. Есть. чтобы не генерировало пустые записи, займет несколько часов.
Здесь вопрос не в пустых, а в том что система сейчас заполняет для всех БП в которые добавляется товар, а нам нужно только например для одного БП
09.03.2023, 16:45
Оригинальный комментарий доступен на версии: ua
там есть возможность выбирать БП, если БП будет не тот что выбран то не будем подставлять
09.03.2023, 17:13
.dev
OneBox production писал/а:
там есть возможность выбирать БП, если БП будет не то что выбран то не будем подставлять
Ок, спасибо, посмотрим в эту сторону
09.03.2023, 17:52
Оригинальный комментарий доступен на версии: ua
.dev
OneBox production писал/а:
да, нужно в тот же момент смотреть какие тяжелые запросы висят в базу данных, по ним можно понять какой модуль их делает и уже двигаться дальше.
Добрий день
По БД увидели что система отправляет много запросов такого формата: "SELECT * FROM `novaposhtacontragentcontact` USE INDEX (index_refplatformid) WHERE `counterpartyRef`=........."
Увидели что в выборках система выбирает данные по клиентам с которыми были относить год и больше (т.е. какие-то неактуальные данные выбирает, то есть похоже, что перебирает все данные)
Сразу после выборки идут запросы такого формата: "UPDATE `novaposhtacontragentcontact` SET `CounterpartyProperty`='Recipient', `Description`=......"
И это делается регулярно.
Таких запросов получается примерно по 12 000 в течение нескольких секунд
Соответственно идет перегрузка на процессор.
Можете подсказать для чего система делает так много запросов регулярно по достаточно старым данным и что можно сделать, чтобы система этого не делала?
14.06.2023, 11:41
Оригинальный комментарий доступен на версии: ua
12к update запросов в таблицу с 12к записями не дадут никакой нагрузки.
Это обновление списка контрагентов отправителей/получателей из новой почты.
Это обновление списка контрагентов отправителей/получателей из новой почты.
14.06.2023, 13:32
.dev
OneBox production писал/а:
12к update запросов в таблицу с 12к записями не дадут никакой нагрузки.
Это обновление списка контрагентов отправителей/получателей из новой почты.
Все зависит от параметров сервера + от других нагрузок
А оно получается так что есть другие нагрузки + эти и как результат все подвисает
Вы можете подсказать почему система обновляет все записи всех клиентов и причем делает это не ночью, а регулярно (возможно и каждые 5 минут)?
Просто с точки зрения рациональности это ненормально (регулярно пытаться обновить данные по всем клиентам, как минимум можно обновить только по тем клиентам, у которых были изменения и делать это не так часто и в ночное время).
14.06.2023, 13:48
Оригинальный комментарий доступен на версии: ua
Юля писал/а:
(возможно и каждые 5 минут)
раз в время максимум
Юля писал/а:
Просто с точки зрения рациональности это ненормально (регулярно пытаться обновить данные по всем клиентам, как минимум можно обновить только по тем клиентам, у которых были изменения и делать это не так часто и в ночное время).
Ну, если Вы так утверждаете, то ок. Вы можете отключить эту функцию.
Что от меня вы ожидаете в данной ситуации я не совсем понимаю? У Вас насколько я понимаю mvp, малейшего вмешательства в код mvp я делать не буду. Вы говорите что Вам не нравятся какие то запросы? Ок, уберите их.
Вот меня что нужно?)
14.06.2023, 15:33
Оригинальный комментарий доступен на версии: ua
Пожалуйста, присоединяйтесь к диалогу. Если вам есть что сказать - пожалуйста, напишите комментарий. Для входа потребуется мобильный телефон и смс-код для идентификации.
Войти и написать комментарий
Copyright © OneBox 2024
