Как я могу загрузить 1000 узлов в час на живой сайт drupal 7 и избежать тупиков?

9

Не так давно я писал о взаимоблокировке здесь: PDOException: SQLSTATE [40001]: Ошибка сериализации: 1213 Обнаружена взаимоблокировка при попытке получить блокировку;

Несмотря на все, что пытается сделать моя команда разработчиков, мы по-прежнему получаем такие ошибки:

PDOException: SQLSTATE [40001]: ошибка сериализации: 1213 Обнаружена тупиковая ситуация при попытке получить блокировку; попробуйте перезапустить транзакцию: INSERT INTO {location_instance} (nid, vid, uid, genid, lid) VALUES (: db_insert_placeholder_0,: db_insert_placeholder_1,: db_insert_placeholder_2,: db_insert_placeholder_3,: db_insert_placeholder Массив ([: db_insert_placeholder_0] => 1059 [: db_insert_placeholder_1] => 1059 [: db_insert_placeholder_2] => 0 [: db_insert_placeholder_3] => cck: field_item_location: 1059 [: местоположение db_insert_placeholder_4] (1000) (1000) (1000) (1000) (1000) (1000) (1000) (1000) (1000) (1000) (1000) (1000) (1000) (1000) (1000) (1000) (1000) ()) = 1000) /var/www/website.com/sites/all/modules/location/location.module).

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

Вот моя ситуация. Я взял большой университетский проект. В любое время есть 50 000 жителей кампуса, которые используют систему ежедневно. В дополнение к этому, я перенесу сотни тысяч единиц контента как вручную, так и с помощью пользовательского кода модуля (миграция из старых университетских данных) на этот новый сайт Drupal 7.

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

Но это более или менее мой вопрос - как Drupal может справляться с таким типом нагрузки? Как я могу организовать свой рабочий процесс, чтобы справиться с такой большой деятельностью? Это проблема Drupal? Проблема с базой данных?

В частности, я использую Ubuntu, LAMP стек 16 ГБ ОЗУ. Я открыт для любых предложений, будь то Drupal, база данных, конфигурация сервера или другой рабочий процесс для работы в рамках возможностей Drupal, поэтому не стесняйтесь предлагать что-нибудь, если у вас есть опыт в этой большой деятельности.

blue928
источник
Есть статья об импорте большого набора данных evolvingweb.ca/story/…
kalabro
Спасибо за это. Очень приятно видеть, что объемы данных действительно могут быть импортированы практически мгновенно. Однако как насчет вопроса о том, что отдельные пользователи публикуют свои собственные учетные записи через формы узлов? По мере того, как я копаюсь и углубляюсь в эту проблему, в моей голове растут риторические вопросы: «Может ли Drupal справиться с таким большим количеством живого трафика? Если нет, то какой в ​​этом смысл?» Помимо импорта, у нас около 20 человек, которые обычно добавляют контент через свои аккаунты. Может ли Drupal 'node save' обрабатывать только 20 пользователей, одновременно добавляющих данные?
blue928
Мы протестировали наш сайт на Drupal с Apache JMeter, используя MySQL и PostgreSQL. Для MySQL наши результаты были около 20 узлов. Для PostgreSQL результаты были намного лучше.
Калабро

Ответы:

5

Я работаю в Стэнфордском университете и занимаюсь подобными вещами. Нам постоянно приходится загружать более 100 000+ узлов на регулярной основе. Мы работали над нашим собственным пользовательским кодом загрузки уже 2 года, и теперь с помощью pcntl_fork смогли значительно ускорить процесс. Единственное, что вы должны помнить, это закрыть все сокеты, прежде чем вызывать форк. Например, вы должны закрыть соединение MySQL, соединение Memcache и даже соединение Монго. Drupal автоматически создаст новые соединения, когда они не существуют. Что касается проблемы тупика, мы смогли решить эту проблему, поставив innodb_locks_unsafe_for_binlog = 1.

Патрик
источник
Вы загружаете их в пакет с пользовательским кодом или используете некоторые функции API drupal, такие как node_save? Или модуль типа миграции? Также упомянутый код доступен для публичного просмотра? Было бы приятно увидеть, как pcntl_fork интегрирован с drupal, чтобы увидеть, что вы, ребята, преодолели это препятствие. Спасибо за подсказку!
blue928
2

Ответ таков: настройте файл MySQL my.cnf правильно.

После чуть более недели исследований я обнаружил, что Drupal 7 действительно может обрабатывать такой много одновременный входной трафик.

Эти исключения блокировки PDO были связаны с тем, что файл MySQL my.cnf не был оптимизирован правильно. С помощью группы Drupal High Performance и других источников у нашей команды не было ни одного тупика с момента реализации новых параметров конфигурации для MySQL. Мы протестировали наши пакетные сценарии, чтобы имитировать до 500 текущих пользователей, сохраняющих контент без проблем. Проверьте тему здесь.

http://groups.drupal.org/node/260938

В частности, Далин предложил использовать мастер для получения базового файла конфигурации на основе спецификаций сервера и типов таблиц. После использования этого, даже без дальнейшей настройки, тупики прекратились. Вот ссылка на мастер, если вы хотите попробовать его: https://tools.percona.com/wizard

Я буду рад опубликовать файл my.cnf, если кто-нибудь посчитает его полезным.

Хотя проблема взаимоблокировки больше не является проблемой, мы теперь получаем эту ошибку очень часто:

PDOException: SQLSTATE[42000]: Syntax error or access violation: 
1305 SAVEPOINT savepoint_1 does not exist: ROLLBACK TO SAVEPOINT savepoint_1; 
Array ( ) in file_usage_add() (line 661 of /var/www/website.com/includes/file.inc).

Может ли это быть проблемой конфигурации mysql?

blue928
источник
Мы начинаем видеть эту ошибку сами. Вы когда-нибудь находили ответ на свой вопрос?
Trimbletodd