Як я можу завантажувати 1000 тисяч вузлів на годину на веб-сайт Drupal 7 і уникати тупиків?

Не так давно я писав про тупиковий стан тут: PDOException: SQLSTATE [40001]: Помилка серіалізації: 1213 Тупик знайдено при спробі заблокувати;

Незважаючи на все, що намагається зробити моя команда розробників, ми все одно отримуємо такі помилки:

PDOException: SQLSTATE [40001]: Помилка серіалізації: 1213 виявлено тупикову ситуацію при спробі заблокувати; спробуйте перезапустити транзакцію: ВСТУПУЙТЕ в {location_instan} (nid, vid, uid, genid, lid) VALUES (: db_insert_placeholder_0,: db_insert_placeholder_1,: db_insert_placeholder_2,: db_insert_placeholder_3,: db_insert_placehold Масив ([: 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_placehold_slonce__) /var/www/website.com/sites/all/modules/location/location.module).

Незважаючи на конкретну таблицю в цьому прикладі, ми отримуємо цю помилку в інших таблицях.

Ось моя ситуація. Я взяв великий проект університету. У будь-який час є 50 000 мешканців кампусу, які користуються системою щодня. На додаток до цього, я переміщую 100 тисяч з 1000 тисяч елементів вмісту як вручну, так і за допомогою спеціального коду модуля (міграція зі старих даних університету) на новий сайт Drupal 7.

Ця помилка вбиває нас, аж до того, що ми майже готові зняти роботу, яка стоїть за останні роки, і піти з чимось іншим, якщо Drupal не впорається з таким навантаженням.

Але це більш-менш моє питання - як Drupal впорається з таким типом навантаження? Як я можу організувати свій робочий потік, щоб можна було впоратися з такою великою діяльністю? Це питання про Друпал? Проблема з базою даних?

Зокрема, я працюю на Ubuntu, LAMP стек 16 Гб оперативної пам’яті. Я відкритий до будь-яких пропозицій, будь то пов’язаний з Drupal, пов’язаний з базою даних, з конфігурацією сервера чи з іншим робочим потоком, який працює в межах можливостей Drupal, тому не соромтесь запропонувати що-небудь, якщо у вас є досвід роботи з такою великою активністю.

Я працюю в університеті Стенфорда і займаюся подібними справами. Нам постійно доводиться завантажувати понад 100 000+ вузлів на регулярній основі. Ми працюємо над власним користувальницьким кодом завантаження вже 2 роки, і змогли прискорити процес досить великий за допомогою pcntl_fork. Єдине, що вам потрібно запам’ятати - це закрити все з'єднання сокета перед тим, як викликати вилку. Наприклад, ви повинні закрити з'єднання mysql, підключення memcache і навіть з'єднання mongo. Drupal автоматично створить нові з'єднання, коли таких немає. Що стосується проблеми з тупиком, нам вдалося виправити цю проблему, поставивши її innodb_locks_unsafe_for_binlog = 1.

Відповідь: Налаштуйте файл MySQL my.cnf правильно.

Після трохи більше тижня досліджень я виявив, що Drupal 7 дійсно може справлятися з таким багаточасним вхідним трафіком.

Ці тупикові PDOExceptions були пов'язані з тим, що файл MySQL my.cnf не був оптимізований правильно. За допомогою групи з високою продуктивністю Drupal та інших джерел, наша команда не мала жодного єдиного тупика з моменту впровадження нових параметрів конфігурації для 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?

http://dev.mysql.com/doc/refman/5.0/en/innodb-deadlocks.html ця сторінка mysql пропонує зробити те, що робити, коли ви стикаєтеся з тупиком.

Чіткою налаштуванням ваша конфігурація mysql допоможе вирішити цю проблему.