Небольшой словарь отжирает >256мб памяти

Главные вкладки

Аватар пользователя zman zman 5 мая 2011 в 16:03

Добрый день.

Странный косяк возник при импорте небольшого географического иерархического словаря.

Обычно главная страница сайта выдаёт такую стату:
Page execution time was 451.18 ms. Executed 406 queries in 84.65 milliseconds.
Memory usage: Memory used at: devel_init()=2.8 MB, devel_shutdown()=27.66 MB.

Импортировал (вроде небольшой) иерархический словарь (страны-области-города http://www.drupal.ru/node/23269 )
теперь
term_data 11,997 записей, объём 1.3 мегабайта
term_hierarchy 11,997 записей, объёма 432.5 килобайт

До установки словаря, ограничение в php.ini стояло
memory_limit = 50M и этого вполне хватало

Теперь, при редактировании географического иерархического словаря пришлось ставить лимит
memory_limit = 300M (при установке 256mb ругается, говорит маловато)

Page execution time was 34923.13 ms. Executed 8108 queries in 906.32 milliseconds.
Memory usage: Memory used at: devel_init()=2.8 MB, devel_shutdown()=103.86 MB

Performance Logs: Summary
-----------------------------------------
Average memory per page: 48.7 MB
Average ms per page: 2,832.56

Path: admin/content/taxonomy/4
Max Memory (MB) 284mb
Avg Memory (MB) 179mb
ms (Max) 34,870.0
ms (Avg)19,427.0
Query ms (Max) 5,694.0
Query ms (Avg) 580.0
Query Count (Max) 8105
Query Count (Avg) 4407

Performance Logs: Details
------------------------------------
path:admin/content/taxonomy/4
Memory (MB) 284.25
ms (Total) 34870
# Queries 8105
Query ms 905

модулей стоит вроде не много
Blog, Color, Comment, Database logging, Help, Menu, Path, Profile, Statistics, Syslog, Taxonomy, Trigger, Update status
+ Devel, Performance Logging, Administration menu, Content management filter, Hierarchical Select, Advanced help, DB Maintenance, Statistics advanced settings, Token, Tracker 2, User Stats, User Terms, Rules

Почему столько жрётся памяти и столько запросов?
Подскажите где косяки возможны?
Куда копать?

Комментарии

Аватар пользователя Виктор Степаньков ака RxB Виктор Степаньк... 5 мая 2011 в 16:05

Копать в сторону патча от Crea на HS, не знаю правда, приняли его или нет.
Так же, в спокойном состоянии рамы жрётся что-то слишком много - поставить акселлератор, если впс, менять хостинг - если виртуальный

Аватар пользователя zman zman 5 мая 2011 в 16:08

забыл добавить

сервачок мелкий (4х яд.амд) свой

drupal 6.20
PHP 5.3.3
MySQL database 5.1.49

Performance logging APC Disabled
Performance logging details Enabled
Performance logging query Enabled

Аватар пользователя zman zman 5 мая 2011 в 16:12

> в спокойном состоянии рамы жрётся что-то слишком много
27 мегабайт много?
странно, я думал, что это нормально

если выкинуть все свистелки и перделки то можно влезть и в 20мегабайт
но это не принципиально

---------

тут вопрос скорее что происходит
при простом просмотре определённой страницы небольшого иерархического словаря
и с какого фига оно считает сразу всё дерево
хотя нужно только определённую часть

Аватар пользователя zman zman 5 мая 2011 в 16:34

тогда уж скорее кривой импорт

как не хотелось, но наверное придётся ставить дебаггер
смотреть кто как гадит

Аватар пользователя zman zman 5 мая 2011 в 17:06

ну если у людей словари нормально работают существенно бОльшего размера
и если не грешить на глюки встроенного (нестороннего) модуля друпала (как-то вывод небольшого 3х уровневого иерархического словаря)

то видимо отстаются косяки с импортом:

<?php
require_once './includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_DATABASE);

$vid 4// id словаря

$result_countries db_query("SELECT * FROM country");
while (
$country db_fetch_object($result_countries)) {
  
  
$result_regions db_query("SELECT * FROM region WHERE country_id = %d"$country->country_id);
  
  
db_query("INSERT INTO {term_data} (tid, vid, name, description) VALUES (%d, %d, '%s', '%s')"null$vid$country->name'');
  
$cntr_id db_last_insert_id('term_data''tid');
  
db_query("INSERT INTO {term_hierarchy} (tid, parent) VALUES (%d, %d)"$cntr_id0);
  
  while (
$region db_fetch_object($result_regions)) {
    
    
$result_cities db_query("SELECT * FROM city WHERE region_id = %d"$region->region_id);
    
    
db_query("INSERT INTO {term_data} (tid, vid, name, description) VALUES (%d, %d, '%s', '%s')"null$vid$region->name'');
    
$rgn_id db_last_insert_id('term_data''tid');
    
db_query("INSERT INTO {term_hierarchy} (tid, parent) VALUES (%d, %d)"$rgn_id$cntr_id);
    
    while (
$city db_fetch_object($result_cities)) {
      
      
db_query("INSERT INTO {term_data} (tid, vid, name, description) VALUES (%d, %d, '%s', '%s')"null$vid$city->name'');
      
$ct_id db_last_insert_id('term_data''tid');
      
db_query("INSERT INTO {term_hierarchy} (tid, parent) VALUES (%d, %d)"$ct_id$rgn_id);
      
    }
  }
}
?>
Аватар пользователя zman zman 5 мая 2011 в 19:22

ой
какие мы ранимые оказывается
виноват, не хотел задеть

наивно рассуждаю где могут быть косяки

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

мне просто интересно понять кто из модулей тормозит в такой примитивной ситуации

Аватар пользователя Виктор Степаньков ака RxB Виктор Степаньк... 5 мая 2011 в 17:20

Я вам написал причины, у меня был проект более 200 000 терминов в одном словаре, если вы имеете желание заниматься багхантингом с другой стороны, то вперёт.
Кеширование друпальное тут не причём и оно не поможет

Аватар пользователя xxandeadxx xxandeadxx 5 мая 2011 в 17:45

при создании иерархии, друпал делает по sql запросу на каждый термин. соответственно — 11,997 записей = 11,997 запросов

Аватар пользователя zman zman 5 мая 2011 в 17:50

файло hs_taxonomy.module

<?php 

  

// We cache trees, so it's not CPU-intensive to call get_tree() on a term
  // and its children, too.
  
if (!isset($children[$vid])) {
    
$children[$vid] = array();

    

$result db_query(db_rewrite_sql('SELECT t.tid, t.*, parent FROM {term_data} t INNER JOIN  {term_hierarchy} h ON t.tid = h.tid WHERE t.vid = %d ORDER BY weight, name''t''tid'), $vid);

?>

походу это само его кэширование и не работает

Аватар пользователя zman zman 5 мая 2011 в 19:21

>патч от Crea на HS
спасибо, но патчи ставить не буду

разработчик (Wim Leers February 6, 2011) обнадёживает:
«I committed a lot of changes to 6.x-3.x-dev. After they've been tested and a release has been made, we might be able to commit this, if at least a few people with >10K terms confirm that it adds improvements.»
( http://drupal.org/node/544324 )

Аватар пользователя zman zman 5 мая 2011 в 19:26

> если не грешить на глюки встроенного (нестороннего) модуля
> друпала (как-то вывод небольшого 3х уровневого иерархического словаря)

а, понятно, вот моя ошипка
забыл что Hierarchical Selects заменила собою стандартный друпальный модуль вывода словарей

«Drupal core's taxonomy selects are now overridden on the Taxonomy Term form.
They've been replaced by Hierarchical Selects for better scalability.
You can configure it to be used on node forms too!
»

Аватар пользователя zman zman 14 мая 2011 в 18:49

ради эксперимента

таки поставил сначала dev(6.x-3.x-dev 2011-Feb-25) версию Hierarchical Selects
посмотрел стату, тоже самое

откатился на стабильную 6.x-3.7 (2011-Feb-23)
поставил патч hs_high_performance_4.patch

разницы практически нет, памяти жрёт также лихо (300м)
средняя скорость выполнения чуть побыстрее

стабильный Hierarchical Selects 6.x-3.7
Page execution time was 35127.75 ms. Executed 8106 queries in 829.32 milliseconds.
Page execution time was 35532.54 ms. Executed 8107 queries in 908.91 milliseconds.
Page execution time was 35744.65 ms. Executed 8106 queries in 1000.29 milliseconds.
Page execution time was 36885.22 ms. Executed 8107 queries in 1313.19 milliseconds

Hierarchical Selects 6.x-3.7 после патча hs_high_performance_4.patch
Page execution time was 35204.26 ms. Executed 8117 queries in 823.26 milliseconds.
Page execution time was 35310.31 ms. Executed 8116 queries in 835.16 milliseconds

собственно
такие аццкие цифири показываются только при редактировании больших иерархических списков в административном интерфейсе (например города США)

юзеровский интерфейс (с выводом иерарх.списков) работает хорошо
Page execution time was 363.86 ms. Executed 199 queries in 37.18 milliseconds.
Memory used at: devel_init()=2.8 MB, devel_shutdown()=28.85 MB

--------

эрго:
после выполнения mysql запросов (0.8сек)
сам друп является тормозом (35сек) в выводе содержимого (иерархии городов США)

попробую pressflow
( может его заточка под php5 и mysql даст небольшое ускорение )

пока неудалось заставить дебаггер XHProf Code Profiler выводить статистику (времени исполнениея кода) в графическом виде ( failed to shell execute cmd=" dot -Tpng" )
там было бы проще увидеть узкие места друпы 6.20

Аватар пользователя Crea Crea 14 мая 2011 в 18:28

Для редактирования используйте Taxonomy Manager - единственный нормальный редактор таксономии для больших словарей