Цитата |
---|
Антон Козлов пишет: 3) Что все-таки лучше для битрикса - xcache или apc? Перелопатили огромное количество тестов и все друг другу противоречат. |
05.08.2014 08:27:37
|
|||
|
31.07.2014 10:54:41
У гипервизора от MS серверных версий всегда были проблемы с распределением ресурсов CPU для гостевых систем на LInux(впрочем наблюдаются проблемы даже с 2003 сервером) , установка гостю Linux Integration Services (LIS) незначительно повышает утилизацию ресурсов - на 5-10%, но понятно положение не спасает. Неоднократно наблюдал как у гостя по всем выделенным ядрам 100% загрузка, а на хосте она 20-25%.
Переходите на vmware esxi, если вам нужна стабильная платформа виртуализации для различных гостевых ОС. |
|
|
05.03.2013 09:01:53
В последнее время на нескольких подконтрольных серверах с Centos 6.3 86_64 и установленном BitrixEnv 4.2 наблюдаю проблему с падением nginx:
в messages: kernel: nginx[11115]: segfault at 8 ip 000000000044417e sp 00007fff86fcfe90 error 4 in nginx[400000+ad000] abrt[11180]: Not dumping repeating crash in '/usr/sbin/nginx' kernel: nginx[11159]: segfault at 8 ip 000000000044417e sp 00007fff86fcfe90 error 4 in nginx[400000+ad000] abrt[11182]: Not dumping repeating crash in '/usr/sbin/nginx' .... и в error.log nginx: [alert] 20953#0: worker process 11115 exited on signal 11 (core dumped) [alert] 20953#0: worker process 11159 exited on signal 11 (core dumped) .... Подскажите пожалуйста как бороться. |
|
|
13.11.2012 21:03:41
При включении в главном модуле "Объединять CSS файлы шаблонов в один файл:" стили в публичной части перестают работать. В логе nginx такое:
2012/11/13 20:50:08 [warn] 16695#0: *1203 using uninitialized "usecache" variable.... В детали не вникал, обнаружил сие перетащив КП с BitrixEnv 3.1 на 4.1 c включенной галкой. |
|
|
07.07.2012 11:43:02
Установил BitrixEnv4 на Centos 5.7 x86_64, apc и что-то еще не очень работает:
подскажите пожалуйста как исправить |
|||
|
04.07.2012 13:36:45
Николай, вот тут
|
|
|
30.06.2012 13:20:39
На чистом Centos 6.2 x86_64, с пакетом BitrixEnv действительно ставится:
php-pecl-apc i386 3.1.10-1.2.el6.1 вылечил так: снес bitrixenv, потом yum install php-pecl-apc поставился php-pecl-apc x86_64 3.1.3p1-1.2.el6.1 поставил bitrixenv. По битриксовым попугаям производительность в среднем ниже на 10-15% по сравнению с BitrixEnv3, на КП 11.5.2 Кроме сего еще глюки: 1. При включении мониторинга конфиг nagios.conf создается с неправильными путями: ScriptAlias /nagios/cgi-bin/ "/usr/lib/nagios/cgi-bin/" нужно ScriptAlias /nagios/cgi-bin/ "/usr/lib64/nagios/cgi-bin/" 2. При попытке настроить ntlm авторизацию: PHP Fatal error: Call to undefined method CLdapUtil::SetBitrixVMAuthSupport() in /root/bitrix-env/ntlm_on.php on line 15 Fatal error: Call to undefined method CLdapUtil::SetBitrixVMAuthSupport() in /root/bitrix-env/ntlm_on.php on line 15 The ntlm has been successfully configured. Николай, полагаю поправить репозитарий и некоторые скрипты нетрудно?
|
|||||
|
17.12.2011 17:34:30
Временно решил проблему добавлением в конфиг nginx bitrix.conf :
location ~* \.(gif|jpg|jpeg|png)$ { try_files $uri =304; } 304, потому что 404 категорически не работает, если поставить 404, то на отсутствующие картинки отдается 200 в течении нескольких секунд. Видимо это нюанс работы nginx 1.*, потому что в версия оного 0.6.39 при указании "error_page 404 = /404.php;" в моем случае на отсутствующие картинки отдает 404 а не 200. В общем вопрос все еще актуален - как заставить nginx отдавать для проблемных изображений 404 и чтобы при этом на несуществующие страницы осуществлялся редирект на /404.php |
|
|
16.12.2011 13:09:59
При размещении копии рабочего сайта на vps с bitrix-env 3.05 проявилась проблема с обработкой отсутствующих или ненайденных по пути изображений в шаблонах, firebug в ff показывает, что такие картинки отдаются с 200 OK в течении 1-2 сек, на рабочем vps с bitrix-env 1.6 на тех же страницах по такими изображениям 404 и никакого ожидания - отдается мгновенно. В результате на копии некоторые страницы формируются по 5-10 сек.
Если закоментировать строку "error_page 404 = /404.php;" в секции "http" nginx.conf страницы отдаются мгновенно, перемещение строки в секцию "server" уменьшает время отклика но не кардинально. К сожалению вычистить все шаблоны от ошибок с путями на несуществующие изображения проблематично, поскольку их много да и сайт постоянно модифицируется и появление подобных ошибок все равно неизбежно. Подскажите как можно это исправить? |
|
|
09.12.2011 11:22:47
При запуске vmbitrix под hyper-v описанные выше проблемы с производительностью наблюдаю:
Производительность конфигурации на 09.12.2011 09:29:27 составляет 28.02 Подсистема Оценка Эталон Примечание Конфигурация 28.02 30 Среднее время отклика 0.0357 0.0330 секунд Процессор (CPU) 6.5 9.0 миллионов операций в секунду Файловая система 16 349.4 10 000 файловых операций в секунду Почтовая система 0.0065 0.0100 время отправки одного письма (в секундах) Время старта сессии 0.0154 0.0002 секунд Конфигурация PHP оптимально оптимально рекомендации База данных MySQL (запись) 2 458 5 600 количество запросов на запись в секунду База данных MySQL (чтение) 7 112 7 800 количество запросов на чтение в секунду База данных MySQL (изменение) 3 486 5 800 количество запросов на изменение в секунду шаманство с распределением ресурсов для виртуальной машины ни к чему не привело, видимо дело в каких то нюансах работы гипервизора от ms. Установка последней версии пакетов интеграции 3.2 не как не отразилось. На том же компьютере под vmware: Производительность конфигурации на 09.12.2011 11:21:46 составляет 110.16 Подсистема Оценка Эталон Примечание Конфигурация 110.16 30 Среднее время отклика 0.0091 0.0330 секунд Процессор (CPU) 10.3 9.0 миллионов операций в секунду Файловая система 15 543.2 10 000 файловых операций в секунду Почтовая система 0.0601 0.0100 время отправки одного письма (в секундах) Время старта сессии 0.0001 0.0002 секунд Конфигурация PHP оптимально оптимально рекомендации База данных MySQL (запись) 6 582 5 600 количество запросов на запись в секунду База данных MySQL (чтение) 14 308 7 800 количество запросов на чтение в секунду База данных MySQL (изменение) 8 226 5 800 количество запросов на изменение в секунду |
|
|
30.11.2011 10:42:52
После разворачивания копии сайта на VMBitrix 3 на рабочем компьютере под VMware получаю ужасную картину, гл.страница:
Время создания страницы: 20.3574 сек. Всего SQL запросов: 21 Время исполнения запросов: 0.0095 сек. Объем кеша: 305 КБ 99% времени тратится на загадочную строчку "PHP код" при этом: Производительность конфигурации на 30.11.2011 10:10:33 составляет 107.40 Разработчики сайта кивают на "хостинг", мол ядро битрикса по каким-то причинам на хостинге так отрабатывает. Сайт в данный момент работает на vps c 1024Мб памяти, оный покупался с шаблоном VMBitrix1.6 и с тех пор менялись только конфиги mysql под растущую бд. На рабочем хостинге таких проблем нет. Версия битрикса 11.04 Подскажите пожалуйста - "где копать"? |
|
|
03.10.2011 19:58:00
Ничего по существу тп([TID#245086]) не сообщило, ни откуда появилось миллион триста тысяч строк звездочек в таблице b_cache_tag ни что делать дальше толком, единственная рекомендация обновить ядро до 11 бета версии битрикса, остальное процитирую:
1. Откуда появились такие значения(*) в таблице кеша? Это кеш, который нужно удалить. 2. Почему на каждой странице выполняется запрос вида с каждой страницы сайта осуществляется запрос SEL ECT * fr om b_cache_tag WHERE TAG='*' Агент удаления кеша срабатывает каждую секунду. 3. Почему отключение управлемого кеша в настройках на содержимое таблицы и наличие/отсутствие запроса на каждой странице никак не влияет, это хорошо видно на ********(доступ в панель такой же) Это и не должно влиять. 4. В общем хотелось бы знать ответ, каков механизм появления таких записей с "*" в таком огромном количестве? Если Вас интересует конкретно механизм, то увидеть его можете в файле /bitrix/modules/main/classes/general/cache_files.php А если в общем - кеш имеет свойство устаревать: по истечении какого-то времени или когда информация в кеше перестаёт быть актуальной. Выше мы написали как устраняется эта ошибка. Вы выполнили рекомендации? |
|
|
30.09.2011 23:36:28
1355226
содержимое таблицы довольно странное, все 1355226строк такие:
SEL ECT * fr om b_cache_tag WHERE TAG='*' , на него уходит 3-6 сек., откуда такое содержимое появилось в таблице непонятно, разработчики сайта ничего сказать не могут внятного, написали в тп битрикса. |
||||||||||||||||||||||||||||||||||||||||||||||
|
30.09.2011 16:39:21
Здравствуйте! После переноса сайта на vps с виртуального хостинга с завидной регулярностью появляется:
MySQL Query Error: SEL ECT * fr om b_cache_tag WHERE TAG='*'[MySQL client ran out of memory] DB query error. Please try later. Пробовал отключать управляемый кеш - тоже самое. Помогите с идеями где копать. |
|
|