1b.app
Скопійоване посилання -

Раз на добу система аномально навантажується на 2-4 годни, що це може бути

На протязі місяця, майже кожну добу, в різний періоди часу, але часто під ранок, система аномально навантажується.
Хостер сказав що навантаження створює база данних
Також сказав що те що показує панель більше 100% навантаження на процессор, це якийсь баг, такого бути не може.
Підвищили тариф на сервері, але це глобально не допомогло.
Система в цей період дуже тормозить, але працює.
Що це може бути (думали що це можлиов розетка оновлює свої довідники, вимкнули автоматизацію в довідниках + вимкнули оновлення категорій розетка, але нічого не допомогло) ?

Відповіді:

Добридень.
1. Навантаження на CPU може бути більше 100%. Це означає, що завдання, які потрібно виконати в секунду на X% більше, ніж процесор може виконати. Наприклад, якщо процесор на сервері може виконати 1000 завдань в секунду, а в черзі 1500, то у вас буде навантаження на cpu 150% в цей момент. Це якщо прям сильно спростити.
2. Швидше за все в цей час на сервері запускається якесь ресурсомістке завдання. Якщо у вас версія продукту - os, ми можемо провести аналіз навантаження у вказаний час і дати поради, як з цим боротися, це займе близько 3год.
27.02.2023, 13:15
Оригінальний коментар доступний на версії: ru

Юля
менеджер
1. А якось можна хоча б теоретично зрозуміти що це може бути за завдання (якщо таких явних, складних не виставлялось), тобто є якісь такі завдання які регулярно система раз на добу виконує, тобто якісь системні ?

2. Якщо на сервері через команду TOP показую що процессор навантажує база даних, можна якось зрозуміти що це може буди (що за задача чи з якою таблицею БД працює процессор) ?
27.02.2023, 13:27


Юля писал/а:
А якось можна хоча б теоретично зрозуміти що це може бути за завдання (якщо таких явних, складних не виставлялось), тобто є якісь такі завдання які регулярно система раз на добу виконує, тобто якісь системні ?

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


Юля писал/а:
2. Якщо на сервері через команду TOP показую що процессор навантажує база даних, можна якось зрозуміти що це може буди (що за задача чи з якою таблицею БД працює процессор) ?

да, нужно в тот же момент смотреть какие тяжелые запросы висят в базу данных, по ним можно понять какой модуль их делает и уже двигаться дальше.
27.02.2023, 13:29

Юля
менеджер

.dev
OneBox production написав:
Так, потрібно в той же момент дивитися які важкі запити висять у базі даних, по них можна зрозуміти який модуль їх робить і вже рухатися далі.

А де можна подивитись ці "важкі запити"?
27.02.2023, 13:41
Оригінальний коментар доступний на версії: ru

у самій базі даних у момент навантаження, у логах важких запитів на базі динних. На жаль, більш конкретно я вам сказати не можу, оскільки не займаюся навчанням адміністрування баз даних і вилову причин навантаження.
27.02.2023, 13:44
Оригінальний коментар доступний на версії: ru

Юля
менеджер
1. А це нормально (згідно з скріна) що збільшується навантаження тільки на процессор, а наприклад оперативка не збільшується ?
2. Подібне навантаженням можуть давати якісь "пошукові роботи гугл" чи щось подібне ?
27.02.2023, 15:19

1. цілком
2. Якщо у вас є сайт, то так - Google може індексувати його.
27.02.2023, 15:53
Оригінальний коментар доступний на версії: ru

так само вас можуть "парсити" якісь інші сервіси.
27.02.2023, 15:53
Оригінальний коментар доступний на версії: ru

Юля
менеджер
Прикладаю статистику з phpMyAdmin
Згідно статистики 3 275 000 запитів select на годину
Тобто виходить що 3 275 000 / 60 = 54583 (за хвилину) / 60 = 909 (за секунду)
Виходить що маже 1000 запитів за секунду
Якось наче забагато
06.03.2023, 10:23


Юля писав/ла:
Якось наче забагато

дивлячись із чим порівнювати. Все залежить від складності запитів, наприклад, мій пк робить 100 000 записів в базу даних за 10 секунд і при цьому вантажить ядра менш ніж на 15%. Тобто. 10 000 записів за секунду. Читання при цьому в кілька разів простіше, ніж записи.
Якщо для вашого сервера це проблема, я можу вирішити її тільки якщо у вас os. На жаль, нічого зробити з кодом на mvp я не можу, ця версія продукту не підтримується. Ви можете самі відбажати складні запити, знайти їх і переписати чи зробити будь-яку іншу оптимізацію вашого сервера. Почати можна з відключення дій "раз на годину" наприклад, можливо вантажить перерахунок цін або щось ще. Також спробуйте подивитися в лог запитів до сервера в nginx, можливо там будуть запити на сторінки вашого сайту і хтось Вас парсить, так ви зможете додати його ip наприклад. Втім тут тисячі варіантів того, чому ваш сервер тупить і всі вони можна вирішити.
06.03.2023, 20:47
Оригінальний коментар доступний на версії: ru

Юля
менеджер

.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

Юля
менеджер
Трохи помоніторивши видно що періодично виникає якесь навантаження в 3000-4000 запитів на секунду, це при нормальних показниках процессор, схоже що в піки навантаження ці запити виникають кожну секунду і потім йде велике навантаження.
Подивившись розмір таблиць, є таблиця додаткових полів "shopcustomfield" вона має приблизно 3 100 000 записів і розмір 1Гб
Можливо такий показник таблиці "shopcustomfield" і створює таку кількість запитів і таку проблему, чи це приблизно нормальні показиники для цієї таблиці ?
07.03.2023, 11:04

Юля
менеджер
Є запити і по 23 000
07.03.2023, 11:12


Юля писав/ла:
А статистика як показує "запити" тобто кількість SELECT за секунду

SELECT у більшості випадків у кілька разів легше по навантаженню для БД ніж INSERT, тому я навів вам приклад саме з INSERT. Тобто. якщо я виконую 10к вставок, то легко зможу виконати стільки ж читань.

Юля писав/ла:
Можливо такий показник таблиці "shopcustomfield" і створює таке кількість запитів і таку проблему, чи це приблизно нормальні показники для цієї таблиці?

це відносно нормальна кількість даних
Я бачу Ваші графіки, але на жаль можу тільки сказати, що вони дуже красиві, більше в них для мене немає жодної цінної інформації. Так, у вас відносно багато запитів, які незрозуміло хто, коли та з якою метою робить. Рішення я писав вище, якщо у вас os (судячи з усього, це не так), дайте посилання на ваш бокс і я Вам допоможу. Якщо у вас mvp – дебаг запитів у бд повністю на Ваших плечах.
07.03.2023, 12:55
Оригінальний коментар доступний на версії: ru

Юля
менеджер

.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


Юля писав/ла:
Ви говорити про 10 000 доданих записів
А статистика показує 1000 запитів (тобто, наприклад, один запит може вибрати/додати/обновити 10 000 записів і це вже за сукню буде 1000 * 10 000 це ж трохи різні речі).

Ви не зрозуміли, про що я. Вважайте, що я Вам нічого не писав про к-во запитів.

Юля писав/ла:
Але виходить що система на базі цієї галочки "Автоматично заповнювати з фільтра товару" заповнює поля по всіх БП куди додаються товари і в результаті збільшується кількість записів у таблиці в рази, тобто замість 1 запису, їх в результаті стає 20 20 БП).

Ви не з того почали. ВИ НЕ ЗНАЄТЕ ЯКІ ЗАПРОТИ ЙДУТЬ В БД. Але при цьому починаєте щось припускати і зменшувати якісь таблиці, в які можливо взагалі не йдуть запити. Вам потрібно з'ясувати:
1. Які запити
2. Звідки
3. У якій кількості
йдуть у базу, а потім вже вирішувати що з цими запитами робити. Не навпаки. Якщо у вас немає програміста/системного адміністратора, який може провести цей аналіз, можете не витрачати свій час, ви нічого не знайдете. Те що ви почали тикати в рандомні таблиці і робити якісь припущення може пофіксувати проблему а може і ні, спроб "поправити" якісь таблиці у вас близько 300 + -, як і до таблиць. Ви кожну так чіпатимете? А друг всі ці 1000 запитів на секунду йдуть у таблицю novaposhtainvoice і не залежать від к-ва даних там?
07.03.2023, 14:10
Оригінальний коментар доступний на версії: ru

Юля
менеджер

.dev
OneBox production писал/а:
Ви не з того почали. ВИ НЕ ЗНАЄТЕ ЯКІ ЗАПРОТИ ЙДУТЬ В БД. Але при цьому починаєте щось припускати і зменшувати якісь таблиці, в які можливо взагалі не йду

Дякую, є таке, йдеш в магазин за хлібом, виходить з пакетом інших товарів :)
Спробуємо почати з того.

Підскажете рішення по проблемі нижче ?

Наприклад в додаткових полях продуктів процессу є галочка яку ми використовуємо "Автоматично заповнювати з фільтра товару"
Так от виходить у нас наприклад є 50 додаткових полів продуктів процессу які ми використовуємо в одному з 20 процессів, а в інших не використовуємо
Але виходить що система на базі цієї галочи "Автоматично заповнювати з фільтра товару" заповнює поля по всім БП куди додаються товари і як результате збільшується кількість записів в таблиці в рази, тобто замість 1 запису, їх в результаті стає 20 (якщо товар додали у всі 20 БП).

Можливо є рішення як зробити так щоб ця галочка "Автоматично заповнювати з фільтра товару" спрацьовувала тільки на конкретному БП або може є дія в БП яка буде копіювати фільтри товарів в продукти процессу (тобто зворотня дія дії "Додати фільтра товару з додаткових полів процесу") або може є якась дія яка може вилучати додаткові поля продуктів процессу ?
09.03.2023, 14:35

к-во select не залежить від к-во значень у shopcustomfield, тобто. ви копаєте не туди
09.03.2023, 14:38
Оригінальний коментар доступний на версії: ru

Юля
менеджер

.dev
OneBox production писал/а:
к-во select не залежить від к-во значень у shopcustomfield, тобто. ви копаєте не туди


Питання більш за все не пов'язано з основною проблемою, просто хотілось би його також вирішити, тому що воно по суті впливає на об'єм БД і як результат на роботу сервера в цілому (тобто база росте і як результат для неї потрібен кращий сервер)
Можете запропонувати якесь рішення щоб вирішити описану проблему ?
09.03.2023, 14:57


Юля писал/а:
Можете запропонувати якесь рішення щоб вирішити описану проблему ?

если у вас mvp, я не могу дать вам какое то решение. Если вы перейдете на os я смогу его предоставить.
09.03.2023, 14:59

Юля
менеджер

.dev
OneBox production писал/а:
Если вы перейдете на os я смогу его предоставить.

Відносно переходу то ми зараз знаходимось в стані прийняття рішення (є ряд проблем переходу, в тому числі і сайт)
Наразі на OS рішення також немає, потрібно робити доопрацювання ?
09.03.2023, 15:47

можна буде зробити налаштування, щоб не заповнювало значення, якщо його немає у фільтрі. Тобто. щоб не генерувало порожні записи, займе кілька годин.
09.03.2023, 16:38
Оригінальний коментар доступний на версії: ru

Юля
менеджер

.dev
OneBox production писал/а:
можна буде зробити налаштування, щоб не заповнювало значення, якщо його немає у фільтрі. Тобто. щоб не генерувало порожні записи, займе кілька годин.


Тут питання не в порожніх, а в тому що система зараз заповнює для всіх БП в які додається товар, а нам потірбно тільки наприклад для одного БП
09.03.2023, 16:45

там є можливість вибирати БП, якщо БП буде не той що обраний то не будемо підставляти
09.03.2023, 17:13
Оригінальний коментар доступний на версії: ru

Юля
менеджер

.dev
OneBox production писал/а:
там є можливість вибирати БП, якщо БП буде не той що обраний то не будемо підставляти


Ок, дякую, подивимось в цю сторону
09.03.2023, 17:52

Юля
менеджер

.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

12к update запитів до таблиці з 12к записами не дадуть ніякого навантаження.
Це оновлення списку контрагентів відправників/отримувачів із нової пошти.
14.06.2023, 13:32
Оригінальний коментар доступний на версії: ru

Юля
менеджер

.dev
OneBox production писал/а:
12к update запитів до таблиці з 12к записами не дадуть ніякого навантаження.
Це оновлення списку контрагентів відправників/отримувачів із нової пошти.

Все залежить від параметрів сервера + від інших навантажень
А воно виходить так що є інші навантаження + ці і як результат все підвисає

Ви можете підсказати чому система оновлює всі записи всіх клєінт і причому робить це не вночі, а регулярно (можливо і кожні 5 хвилин) ?

Просто з точки зору раціональності це ненормально (регулярно намагатись оновтити дані по всіх клієнтах, як мінімум можна оновити тільки по тих клієнтах в яких були зміни і робити це не так часто і в нічний час)
14.06.2023, 13:48


Юля писал/а:
(можливо і кожні 5 хвилин)

раз в час максимум


Юля писал/а:
Просто з точки зору раціональності це ненормально (регулярно намагатись оновтити дані по всіх клієнтах, як мінімум можна оновити тільки по тих клієнтах в яких були зміни і робити це не так часто і в нічний час)

Ну если Вы так утверждаете, то ок. Можете отключить эту функцию.
Что от меня Вы ожидаете в данной ситуации я не совсем понимаю? У Вас насколько я понимаю mvp, малейшего вмешательства в код mvp я делать не буду. Вы говорите что Вам не нравятся какие то запросы? Ок, уберите их.

От меня что нужно?)
14.06.2023, 15:33

Будь ласка, приєднуйтесь до діалогу. Якщо вам є що сказати – будь ласка, напишіть коментар. Для входу потрібний мобільний телефон та смс-код для ідентифікації. Увійти та написати коментар