Если разработчик вам так ответил, то это его характеризует не с лучшей стороны.
Как бы год консультации и всевозможной помощи консультации подразумевалось, но после того как оплата поступила на счет, все! Общение только с менеджером(его работу я понял, тянуть время и говорить много красивых слов).
про первый вопрос - в шапке есть меню, но его не видно, т.к. оно такого же цвета как и фон шапки, как цвет ссылок этого меню сделать белым ? при этом чтобы другие меню сайта остались прежднего цвета ?
Попытки решить проблему нашего сис. админа он конечно признался мне что в вебе неочень, но все таки попытался. Переписка нашего админа поддержкой UMI.CMS:
Мля, вот из-за одной очепятки теперь мучайся, пересылай все )
Читать снизу вверх
Здравствуйте.
Однако, у нас такие запросы часто наблюдаются среди медленных (> 2 сек).
2 х Xeon 2000 MHz (виртуальный выделенный сервер)
2 Gb RAM
Например, вот из свежего:
[root@lada ~]$ tail -n 20 /var/log/mysql_slow_queries.log
# Query_time: 13.088721 Lock_time: 0.000045 Rows_sent: 38 Rows_examined: 38
SET timestamp=1287415118;
SELECT field_id, int_val, varchar_val, text_val, rel_val, tree_val, float_val FROM cms3_object_content WHERE obj_id = '45761';
# User@Host: ladakz_dbuser[ladakz_dbuser] @ localhost []
# Query_time: 4.329452 Lock_time: 0.000059 Rows_sent: 10 Rows_examined: 10
SET timestamp=1287415118;
SELECT field_id, int_val, varchar_val, text_val, rel_val, tree_val, float_val FROM cms3_object_content WHERE obj_id = '27227';
# User@Host: ladakz_dbuser[ladakz_dbuser] @ localhost []
# Query_time: 5.594441 Lock_time: 0.000081 Rows_sent: 4 Rows_examined: 4
SET timestamp=1287415118;
SELECT field_id, int_val, varchar_val, text_val, rel_val, tree_val, float_val FROM cms3_object_content WHERE obj_id = '44096';
# User@Host: ladakz_dbuser[ladakz_dbuser] @ localhost []
# Query_time: 3.953360 Lock_time: 0.000073 Rows_sent: 11 Rows_examined: 11
SET timestamp=1287415118;
SELECT field_id, int_val, varchar_val, text_val, rel_val, tree_val, float_val FROM cms3_object_content WHERE obj_id = '2373';
# Time: 101018 21:29:43
# User@Host: ladakz_dbuser[ladakz_dbuser] @ localhost []
# Query_time: 5.991091 Lock_time: 0.000044 Rows_sent: 0 Rows_examined: 1
SET timestamp=1287415783;
DELETE FROM cms3_object_content WHERE obj_id = '44704' AND (field_id = '8792');
Заметьте, что в условии для DELETE указывается не только объект, но и поле. Разве у одного объекта в одном поле может быть больше одной записи?
Сейчас появились еще долгие SELECT из cms3_object_content
Возможные причины:
1. Фрагментированный кэш запросов (я его всего 2 дня не дефрагментировал). Фрагментация кэша составила 21%. Сейчас я сделал FLUSH TABLE CACHE и уменьшил query_cache_min_res_unit до 2 K (было 4 К)
2. Фрагментированная таблица (также 2 дня не касался). В данный момент решил ничего с ней не делать, вдруг у вас идеи появятся проверить что-то.
Напомню, что непосредственно перед письмом в техподдержку я выгружал БД, удалял ИнноДБ-файлы и загрузил базу обратно.
Здравствуйте, Игорь,
Мы проконсультировались с разработчиками. Использование сочетания DELETE+INSERT связано с особенностью архитектуры системы UMI.CMS. Таким образом решается проблема, когда одному объекту соответствует большое количество строк в одной таблице. Тогда оказывается быстрее удалить и заново создать записи.Также, использование UPDATE может привести к ошибкам и нарушить целостность данных.
С уважением, Кирилл Новичихин
16.10.2010 09:35 - Игорь Янковский написал(а):
Здравствуйте.
В данный момент я изучаю проблему с нагрузкой на процессор при генерации страниц сайта lada.kz (UMI.CMS Pro Commerce 2.8.1.3, сборка 15820)
Я не исключаю того, что разработчики изменяли оригинальный код UMI
Сразу же оговорюсь, что до недавнего времени с этой КМС я не сталкивался – т.е. уровень моих знаний здесь небольшой
Основную нагрузку в данный момент дает mysql.
Скрипты вроде mysqltuner.pl и tuning-primer.sh ничего плохого не говорят, только про фрагментацию. Ресурсов для mysql выделено достаточно.
Сделано удаление innodb-файлов и загрузка из дампа, чтобы исключить фрагментацию.
Но фрагментация происходит быстро. В логе mysql в первую очередь бросились в глаза транзакции вида
--- cut ---
2 Query START TRANSACTION /* Saving object 27227 */
2 Query DELETE FROM cms3_object_content WHERE obj_id = '27227' AND (field_id = '9321')
2 Query INSERT INTO cms3_object_content (obj_id, field_id, int_val) VALUES('27227', '9321', '141605')
2 Query SELECT field_id, int_val, varchar_val, text_val, rel_val, tree_val, float_val FROM cms3_object_content WHERE obj_id = '27227'
2 Query SELECT SQL_CACHE int_val FROM cms3_object_content WHERE obj_id = '27227' AND field_id = '9321' LIMIT 1
2 Query START TRANSACTION /* Updating object #27227 info */
2 Query UPDATE cms3_objects SET name = 'Новости Актау - Газета ЛАДА', type_id = '776', is_locked = '0', owner_id = '27148', guid = '' WHERE id = '27227'
2 Query COMMIT
2 Query SELECT SQL_CACHE name, type_id, is_locked, owner_id, guid FROM cms3_objects WHERE id = '27227'
2 Query COMMIT
--- cut ---
field_id = '9321'
id - 9321
name - count_view
title - Просмотров
Понятно, что обновляется кол-во просмотров в таблице, но зачем делать DELETE и сразу же INSERT, а не просто UPDATE?
Точно такие же транзакции выполняются при отображении баннеров.
id - 8792
name - views_count
title - i18n::field-views_count
И для изменения последнего посещения пользователя
Id - 8967
Name - last_request_time
Title - i18n::field-last_request_time
Хочется изменить php-код так, чтобы вместо DELETE+INSERT было сразу UPDATE
Или, если при создании объекта поля 9321, 8792, 8967, … могут не создаваться автоматически, усложнить немного, например
SELECT count(*) FROM cms3_object_content WHERE obj_id = '27227' AND (field_id = '9321')
И в зависимости от результата INSERT или UPDATE
Как бы год консультации и всевозможной помощи консультации подразумевалось, но после того как оплата поступила на счет, все! Общение только с менеджером(его работу я понял, тянуть время и говорить много красивых слов).
zexis, что можете посоветовать?
div#main-mid,
div#footer,
.module_menu { border:none; }
C границами разобрались.
На счет ссылки:
color:#fff;
}
flenj, рад помочь!
Доработка шаблонов (внесение изменений в шаблон);
Тогда может дадите ответ на мой вопрос?
Я невижу куда вы добавили эти стили.
Извиняюсь недогледел вместо
div#main-mid,
div.footer { border:none; }
div#main-mid,
div#footer { border:none; }
у меня нету.
color:#fff important;
}
Куданить впихай)
JurisDay,
div#main-mid,
div.footer { border:none; }
Добавьте это в конце tdefaut.css
Так же добавьте в стили.
Шрифты размеры и все остальное думаю сами настроите.
У вас в стилях:
Нужно заменить:
margin:0;
padding:0;
text-align:center;
background:#ffffff url(../images/bg.jpg) 0 0 repeat;
font-size:13px;
color:#672620;
font-family: cambria, tahoma, arial , sans-serif;
font-weight:normal;
}
На
margin:0;
padding:0;
text-align:center;
background:#ffffff;
font-size:13px;
color:#672620;
font-family: cambria, tahoma, arial , sans-serif;
font-weight:normal;
}
http://jurisday.ru//templates/marhance/images/bg.jpg - эта картинка придает вашему фону тот цвет который сейчас есть.
По поводу первого вопроса непонял.
Мне даже стыдно чуть чуть стало:D
asmakovec2, про нагрузку незнал. Ну это так в порядке бреда:)
esetnod, здесь есть люди которые могут помочь?
Нужны профессионалы своего дела.
Попытки решить проблему нашего сис. админа он конечно признался мне что в вебе неочень, но все таки попытался. Переписка нашего админа поддержкой UMI.CMS:
Мля, вот из-за одной очепятки теперь мучайся, пересылай все )
Читать снизу вверх
Однако, у нас такие запросы часто наблюдаются среди медленных (> 2 сек).
2 х Xeon 2000 MHz (виртуальный выделенный сервер)
2 Gb RAM
Например, вот из свежего:
[root@lada ~]$ tail -n 20 /var/log/mysql_slow_queries.log
# Query_time: 13.088721 Lock_time: 0.000045 Rows_sent: 38 Rows_examined: 38
SET timestamp=1287415118;
SELECT field_id, int_val, varchar_val, text_val, rel_val, tree_val, float_val FROM cms3_object_content WHERE obj_id = '45761';
# User@Host: ladakz_dbuser[ladakz_dbuser] @ localhost []
# Query_time: 4.329452 Lock_time: 0.000059 Rows_sent: 10 Rows_examined: 10
SET timestamp=1287415118;
SELECT field_id, int_val, varchar_val, text_val, rel_val, tree_val, float_val FROM cms3_object_content WHERE obj_id = '27227';
# User@Host: ladakz_dbuser[ladakz_dbuser] @ localhost []
# Query_time: 5.594441 Lock_time: 0.000081 Rows_sent: 4 Rows_examined: 4
SET timestamp=1287415118;
SELECT field_id, int_val, varchar_val, text_val, rel_val, tree_val, float_val FROM cms3_object_content WHERE obj_id = '44096';
# User@Host: ladakz_dbuser[ladakz_dbuser] @ localhost []
# Query_time: 3.953360 Lock_time: 0.000073 Rows_sent: 11 Rows_examined: 11
SET timestamp=1287415118;
SELECT field_id, int_val, varchar_val, text_val, rel_val, tree_val, float_val FROM cms3_object_content WHERE obj_id = '2373';
# Time: 101018 21:29:43
# User@Host: ladakz_dbuser[ladakz_dbuser] @ localhost []
# Query_time: 5.991091 Lock_time: 0.000044 Rows_sent: 0 Rows_examined: 1
SET timestamp=1287415783;
DELETE FROM cms3_object_content WHERE obj_id = '44704' AND (field_id = '8792');
Заметьте, что в условии для DELETE указывается не только объект, но и поле. Разве у одного объекта в одном поле может быть больше одной записи?
Сейчас появились еще долгие SELECT из cms3_object_content
Возможные причины:
1. Фрагментированный кэш запросов (я его всего 2 дня не дефрагментировал). Фрагментация кэша составила 21%. Сейчас я сделал FLUSH TABLE CACHE и уменьшил query_cache_min_res_unit до 2 K (было 4 К)
2. Фрагментированная таблица (также 2 дня не касался). В данный момент решил ничего с ней не делать, вдруг у вас идеи появятся проверить что-то.
Напомню, что непосредственно перед письмом в техподдержку я выгружал БД, удалял ИнноДБ-файлы и загрузил базу обратно.
Мы проконсультировались с разработчиками. Использование сочетания DELETE+INSERT связано с особенностью архитектуры системы UMI.CMS. Таким образом решается проблема, когда одному объекту соответствует большое количество строк в одной таблице. Тогда оказывается быстрее удалить и заново создать записи.Также, использование UPDATE может привести к ошибкам и нарушить целостность данных.
С уважением, Кирилл Новичихин
16.10.2010 09:35 - Игорь Янковский написал(а):
Здравствуйте.
В данный момент я изучаю проблему с нагрузкой на процессор при генерации страниц сайта lada.kz (UMI.CMS Pro Commerce 2.8.1.3, сборка 15820)
Я не исключаю того, что разработчики изменяли оригинальный код UMI
Сразу же оговорюсь, что до недавнего времени с этой КМС я не сталкивался – т.е. уровень моих знаний здесь небольшой
Основную нагрузку в данный момент дает mysql.
Скрипты вроде mysqltuner.pl и tuning-primer.sh ничего плохого не говорят, только про фрагментацию. Ресурсов для mysql выделено достаточно.
Сделано удаление innodb-файлов и загрузка из дампа, чтобы исключить фрагментацию.
Но фрагментация происходит быстро. В логе mysql в первую очередь бросились в глаза транзакции вида
--- cut ---
2 Query START TRANSACTION /* Saving object 27227 */
2 Query DELETE FROM cms3_object_content WHERE obj_id = '27227' AND (field_id = '9321')
2 Query INSERT INTO cms3_object_content (obj_id, field_id, int_val) VALUES('27227', '9321', '141605')
2 Query SELECT field_id, int_val, varchar_val, text_val, rel_val, tree_val, float_val FROM cms3_object_content WHERE obj_id = '27227'
2 Query SELECT SQL_CACHE int_val FROM cms3_object_content WHERE obj_id = '27227' AND field_id = '9321' LIMIT 1
2 Query START TRANSACTION /* Updating object #27227 info */
2 Query UPDATE cms3_objects SET name = 'Новости Актау - Газета ЛАДА', type_id = '776', is_locked = '0', owner_id = '27148', guid = '' WHERE id = '27227'
2 Query COMMIT
2 Query SELECT SQL_CACHE name, type_id, is_locked, owner_id, guid FROM cms3_objects WHERE id = '27227'
2 Query COMMIT
--- cut ---
field_id = '9321'
id - 9321
name - count_view
title - Просмотров
Понятно, что обновляется кол-во просмотров в таблице, но зачем делать DELETE и сразу же INSERT, а не просто UPDATE?
Точно такие же транзакции выполняются при отображении баннеров.
name - views_count
title - i18n::field-views_count
И для изменения последнего посещения пользователя
Name - last_request_time
Title - i18n::field-last_request_time
Хочется изменить php-код так, чтобы вместо DELETE+INSERT было сразу UPDATE
Или, если при создании объекта поля 9321, 8792, 8967, … могут не создаваться автоматически, усложнить немного, например
SELECT count(*) FROM cms3_object_content WHERE obj_id = '27227' AND (field_id = '9321')
И в зависимости от результата INSERT или UPDATE