Сайт умирает при выгрузке товара из 1С, нужна помощь

[mobiopt]

Выгружаем товары (11000 штук) из 1С на сайт с помощью дополнения "Обмен с 1C", если запустить выгрузку 2 раза в течение получаса, то сайт становится не доступен минут на 10.

Проблема с хостингом?

[Otvet]

с нехваткой ресурсов

 

ну или в модуль вшили тормоза чтоб за доработку денег брать

[Tobolskiy]

возможно у вас что то начинает генерироваться... превью фоток например... чаще это сжирает много ресурсов

[mobiopt]

12 minutes ago, Otvet said:

с нехваткой ресурсов

ресурсов чего? просто понять бы к кому обращаться

[buslikdrev]

10 минут назад, Tobolskiy сказал:

превью фоток например... чаще это сжирает много ресурсов

У меня есть замечательный модуль для предгенерации превью фоток - пишите в лс за ссылкой.

[i3bepb]

8 часов назад, mobiopt сказал:

ресурсов чего? просто понять бы к кому обращаться

Надо в момент когда сайт становится недоступным посмотреть состояние веб-сервера, базы. Для начала веб-сервер можно промониторить например через консоль, командой top, для подробностей что смотреть надо погуглить на эту тему. Базу можно посмотреть запросом SHOW FULL PROCESSLIST, много ли запросов в момент зависания и может какие-то запросы зависли.

Ну а дальше уже более подробно надо разбиратся, например видим из top, что процессор загружен, смотрим там же какими процессами. А если видим в базе висящий запрос/запросы, то начинаем разбиратся почему они висят.

Я делаю ставку на то, что будет обнаружены висящие запросы в базе )

[costas]

9 часов назад, mobiopt сказал:

Выгружаем товары (11000 штук) из 1С на сайт с помощью дополнения "NeoSeo Обмен с 1C", если запустить выгрузку 2 раза в течение получаса, то сайт становится не доступен минут на 10.

Проблема с хостингом?

11000 товаров - если на добавление товара, то  по 20+ запросов к БД на каждый товар, итого будет 220000+  запросов примерно.

То есть 10 минут при минимальной конфигурации БД это нормально.

Если хотите что бы "залетало" за минуту - увеличивайте ресурсы БД + тюнинг конфига, для MySQL предела нет по памяти (RAM), сколько не корми

Либо смотреть в сторону PostgreSQL.

 

[i3bepb]

48 минут назад, costas сказал:

11000 товаров - если на добавление товара, то  по 20+ запросов к БД на каждый товар, итого будет 220000+  запросов примерно

Почему именно такое кол-во запросов, алгоритм же можно поразному написать.

49 минут назад, costas сказал:

Либо смотреть в сторону PostgreSQL

А какие плюсы у Posgresql в этом плане перед Mysql, кол-во запросо то остатеся же тем же?

[costas]

11 минут назад, i3bepb сказал:

Почему именно такое кол-во запросов, алгоритм же можно поразному написать.

Алгоритм не влияет на инсерты в таблицы, от перестановки слагаемых сумма не меняется.

Нельзя из двух инсертов в две таблицы, сделать один в те же две таблицы.

13 минут назад, i3bepb сказал:

А какие плюсы у Posgresql в этом плане перед Mysql, кол-во запросо то остатеся же тем же?

гугл в помощь.

[i3bepb]

1 минуту назад, costas сказал:

Алгоритм не влияет на инсерты в таблицы, от перестановки слагаемых сумма не меняется.

Нельзя из двух инсертов в две таблицы, сделать один в те же две таблицы.

Например есть 100 товаров и 2 таблицы, можно на каждый товар делать 2 запроса и получить 100*2=200 запросов, а можно использовать bulk insert и вставить сразу все 100 товаров сначала в одну таблицу, затем во вторую и получить 2 запроса, по запросу на таблицу. Поэтому и пишу, что алгоритм может быть разным

 

7 минут назад, costas сказал:

гугл в помощь.

Зря Вы так, очевидно же если бы в Postgresql запросы SELECT или INSERT делались в разы быстрее, то Posgresql бы убил Mysql. А так это только рождает мифи о том, что вот если бы использовать Postgresql, то не было бы проблем. Postgresql не лучше, не хуже Mysql это просто другая система и все, в которой есть свои плюсы, минусы. Вы даже не знаете какой алгоритм в обновлении товаров, т.е. Вы не знаете какая там проблема и советуете на неизвестную проблему решение - Posеgresql. Хорошо наверное Вы держите в голове какую-то определенную проблему, которую помогает решить Postgresql, когда предлагаете решение. Вы предположили 220000+ запросов, ок, тогда я задал вопрос как Postgresql поможет решить эту проблему, а Вы посылаете в гугл, закрадывается мнение, что Вы и сами не знаете чем поможет Postgresql.

[costas]

1 час назад, i3bepb сказал:

Например есть 100 товаров и 2 таблицы, можно на каждый товар делать 2 запроса и получить 100*2=200 запросов, а можно использовать bulk insert и вставить сразу все 100 товаров сначала в одну таблицу, затем во вторую и получить 2 запроса, по запросу на таблицу. Поэтому и пишу, что алгоритм может быть разным

Полагать, что один запрос который содержит все в одной строке все 100 запросов, будет как то другому обрабатываться архитектурой MySQL и будет работать быстрее - это даже не близко к Junior Database Administrator... без комментариев

 

1 час назад, i3bepb сказал:

Зря Вы так, очевидно же если бы в Postgresql запросы SELECT или INSERT делались в разы быстрее, то Posgresql бы убил Mysql. А так это только рождает мифи о том, что вот если бы использовать Postgresql, то не было бы проблем. Postgresql не лучше, не хуже Mysql это просто другая система и все, в которой есть свои плюсы, минусы. Вы даже не знаете какой алгоритм в обновлении товаров, т.е. Вы не знаете какая там проблема и советуете на неизвестную проблему решение - Posеgresql. Хорошо наверное Вы держите в голове какую-то определенную проблему, которую помогает решить Postgresql, когда предлагаете решение. Вы предположили 220000+ запросов, ок, тогда я задал вопрос как Postgresql поможет решить эту проблему, а Вы посылаете в гугл, закрадывается мнение, что Вы и сами не знаете чем поможет Postgresql.

Исходя из выше сказанного:

В гугл и еще раз в гугл.

[i3bepb]

34 минуты назад, costas сказал:

Полагать, что один запрос который содержит все в одной строке все 100 запросов, будет как то другому обрабатываться архитектурой MySQL и будет работать быстрее - это даже не близко к Junior Database Administrator... без комментариев

Правильно говорит не "все 100 запросов", а все 100 товаров. Вам наверное не знаком термин bulk insert и Вы не понимаете о чем Я написал. Посылаю Вас в гугл по фразе "mysql bulk insert". Да такой один запрос будет обрабатыватся архитектурой mysql по другому, нежели 100 отдельных - для mysql такой запрос пойдет одной транзакцией, а это значит данные на жесткий диск он скинет тоже за раз, а не будет их скидывать 100 раз, также ему надо будет перестроить индексы при появлении новой записи в таблице, это он сделает тоже один раз, а не после каждого запроса на товар. В итоге мы получаем более оптимальную работу с жестким диском и операция перестроения индексов происходит 1 раз, а 100.

 

46 минут назад, costas сказал:

Исходя из выше сказанного:

В гугл и еще раз в гугл.

Это просто возмутительно! )))

[costas]

5 минут назад, i3bepb сказал:

Правильно говорит не "все 100 запросов", а все 100 товаров. Вам наверное не знаком термин bulk insert и Вы не понимаете о чем Я написал. Посылаю Вас в гугл по фразе "mysql bulk insert". Да такой один запрос будет обрабатыватся архитектурой mysql по другому, нежели 100 отдельных - для mysql такой запрос пойдет одной транзакцией, а это значит данные на жесткий диск он скинет тоже за раз, а не будет их скидывать 100 раз, также ему надо будет перестроить индексы при появлении новой записи в таблице, это он сделает тоже один раз, а не после каждого запроса на товар. В итоге мы получаем более оптимальную работу с жестким диском и операция перестроения индексов происходит 1 раз, а 100.

 

Это касается одной таблицы oc_product, это всего один запрос к БД из 20+, после этого запроса потом нужно будет делать поиск product_id что бы продолжить инсерты в связанные таблицы со всеми вытекающими.

 

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

 

В итоге  mysql bulk insert никаким образом в реале не применимы, кроме как дампы, бэкапы и миграции.

[snastik]

1 час назад, i3bepb сказал:

Правильно говорит не "все 100 запросов", а все 100 товаров. Вам наверное не знаком термин bulk insert и Вы не понимаете о чем Я написал. Посылаю Вас в гугл по фразе "mysql bulk insert". Да такой один запрос будет обрабатыватся архитектурой mysql по другому, нежели 100 отдельных - для mysql такой запрос пойдет одной транзакцией, а это значит данные на жесткий диск он скинет тоже за раз, а не будет их скидывать 100 раз, также ему надо будет перестроить индексы при появлении новой записи в таблице, это он сделает тоже один раз, а не после каждого запроса на товар. В итоге мы получаем более оптимальную работу с жестким диском и операция перестроения индексов происходит 1 раз, а 100.

 

Это просто возмутительно! )))

 

Замечательные специалисты.

 

Правды нет ни в одном ни во втором утверждении. Все зависит от структуры таблицы и количества индексов, и даже иногда, как это странно не будет звучать от того что у вас mariadb или mysql.

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

 

Что касается вопроса ТСа - то проблемы могут быть в чем угодно.
В отсутсвии индексов, в некорректной конфигурации mysql сервера, в нехватке ресурса процессора, в плохом коде (откуда правда там взяться хорошему). И эти проблемы существуют почти у всех. Так как разработчик не тестируют свои решения на большом объеме данных. На демо заработало и ок.

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

 

 

[i3bepb]

1 час назад, snastik сказал:

В любом случае любую проблему необходимо первично диагностировать. А в данном случае все советы сводятся к попыткам тыкнуть пальцем в небо.

Золотые слова, я потому с этого и начинал:

 

7 часов назад, i3bepb сказал:

Надо в момент когда сайт становится недоступным посмотреть состояние веб-сервера, базы. Для начала веб-сервер можно промониторить например через консоль, командой top, для подробностей что смотреть надо погуглить на эту тему. Базу можно посмотреть запросом SHOW FULL PROCESSLIST, много ли запросов в момент зависания и может какие-то запросы зависли.

Ну а дальше уже более подробно надо разбиратся, например видим из top, что процессор загружен, смотрим там же какими процессами. А если видим в базе висящий запрос/запросы, то начинаем разбиратся почему они висят.

Я делаю ставку на то, что будет обнаружены висящие запросы в базе )

 

Это уже потом мы с @costas начали писюнами мерится, после того как он пальцем в небо тыкнул.

[snastik]

16 часов назад, i3bepb сказал:

Золотые слова, я потому с этого и начинал:

 

 

Это уже потом мы с @costas начали писюнами мерится, после того как он пальцем в небо тыкнул.

 

От того что вы меряетесь, кроме флуда, ТС не получил никакой полезной информации.

А вот методология ваша не очень, потому что никакой top не покажет вам к примеру такое:

Если я правильно понимаю импорт 1с это форк от @kirilove. И насколько я помню, он использует стандартные методы движка для обновления товаров. И предположим, у него есть дописка, которая сбрасывает кеш сеопро при каждом обновлении товаров, а на фронт при этом идет трафик, который судорожно пытается его сгенерить.

Скажите, какой top его покажет ?

 

Или второй пример. Предположим что там таблицы myisam - ну там это на 99%.
В процессе обмена, естественно становятся все таблицы oc_product_*, и ложится весь магазин, а никто не отменял трафик из мира, и что мы получаем? Экспоненциальный всплеск нагрузки из-за заблокированных таблиц! Но если мы попытаемся сделать explain у тех же запросов, которые допустим, увидим как медленные в логе медленных запросов или в mytop - мы не увидим какой-то проблемы.

[i3bepb]

34 минуты назад, snastik сказал:

Или второй пример. Предположим что там таблицы myisam - ну там это на 99%.
В процессе обмена, естественно становятся все таблицы oc_product_*, и ложится весь магазин, а никто не отменял трафик из мира, и что мы получаем? Экспоненциальный всплеск нагрузки из-за заблокированных таблиц! Но если мы попытаемся сделать explain у тех же запросов, которые допустим, увидим как медленные в логе медленных запросов или в mytop - мы не увидим какой-то проблемы.

 

17 часов назад, i3bepb сказал:

SHOW FULL PROCESSLIST

Если выполнить в момент тормозов покажет эти запросы с большим временем выполнения. Т.е. будет видно прямо какой запрос висит и уже потом разбираться почему он висит. Я же писал наиболее простые действия, возможно которые ТС сможет выполнить самостоятельно и затем дать больше информации о проблеме. А top он даже ситуацию с зависшими запросами отразит. Пример - таблица с товарами заблокировалась, запросы встают в очередь, mysql начинает жрать все больше ресурсов - память, процессор и в top процесс mysql выходит в топ )))

 

@snastik Вы тоже не правы, ТС спросил куда копать - веб-сервер создает нагрузку при создании кэша или в БД какая-то проблема и как раз top даст первоначальное направление. А Вы уже начали писать предположение, что это создание кэша или тип таблицы там myisam вдаваться в тонкости, как это поможет ответить на вопрос ТС:

В 08.05.2020 в 00:56, mobiopt сказал:

ресурсов чего? просто понять бы к кому обращаться

Змінено 9 травня 2020 користувачем i3bepb

[snastik]

Цитата

SHOW FULL PROCESSLIST

 

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

 

37 минут назад, i3bepb сказал:

@snastik Вы тоже не правы, ТС спросил куда копать - веб-сервер создает нагрузку при создании кэша или в БД какая-то проблема и как раз top даст первоначальное направление. А Вы уже начали писать предположение, что это создание кэша или тип таблицы там myisam вдаваться в тонкости, как это поможет ответить на вопрос ТС:

 

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

 

[i3bepb]

9 часов назад, snastik сказал:

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

 

10 часов назад, i3bepb сказал:

Если выполнить в момент тормозов