- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Сайт на битриксе.
Сервер:
Процессор 2x2000МГц
Память 2048МБ
Диск: SSD 20Гб
OS centos6-x86_64
Кэш и прочее включено. Пока сайт создавался - работал быстро. Когда зашли 20 сотрудников одновременно - более-менее. Когда выложили в паблике, умер совсем. "WAIT" более 30 секунд от сервера.
Подумал что косяк в сервере, переложил сайт на хостинг VIP-2 от reg ru, стало еще хуже. Конфиг php выбран 5.4_optimized2 (под xCache)
Основной проблемой вижу забитую память, и отсюда проблема выставить нормальное значение для innodb_buffer_pool_size
>free -m
total used free shared buffers cached
Mem: 2048 1273 774 0 0 1230
-/+ buffers/cache: 42 2005
Swap: 0 0 0
у вас память вовсе не забита а свободна.
остальное нужно смотреть непосредственно на сервере, предоставленной информации недостаточно.
Пока есть свободная память, а она есть, насколько я вижу, крайне маловероятно, что из-за нее.
Сказать что-то больше, довольно сложно.
ну, когда пытаюсь выставить innodb_buffer_pool_size не 80Мб а скажем 300. то mysqld не запускается
ну, когда пытаюсь выставить innodb_buffer_pool_size не 80Мб а скажем 300. то mysqld не запускается
база сколько весит? почему не запускается? с чего вы решили то что отдать 300 хорошая идея?
сам битрикс рекомендует для 2гб отдать 780мб. на их сайте есть пример.
База весит около 70мб (пока что).
Сейчас поставил 780. Запустилось.
Полный конфиг mysql такой:
[client]
default-character-set = utf8
[mysqld_safe]
nice = 0
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
[mysqld]
# Basic mysql server configuration
pid-file = /var/run/mysqld/mysqld.pid
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
skip-external-locking
default-storage-engine = innodb
pid-file = /var/run/mysqld/mysqld.pid
transaction-isolation = READ-COMMITTED
max_allowed_packet = 16M
myisam-recover = BACKUP
expire_logs_days = 10
max_binlog_size = 100M
# Cache parameters
query_cache_size = 32M
table_open_cache = 4096
thread_cache_size = 32
key_buffer = 16M
thread_stack = 128K
join_buffer_size = 2M
sort_buffer_size = 2M
# InnoDB parameters
innodb_file_per_table
innodb_buffer_pool_size = 780M
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
innodb_log_file_size = 64M
# Parameters for temporary tables
tmpdir = /tmp
max_heap_table_size = 32M
tmp_table_size = 32M
# Database charset parameters
character-set-server = utf8
collation-server = utf8_unicode_ci
init-connect = "SET NAMES utf8 COLLATE utf8_unicode_ci"
skip-character-set-client-handshake
skip-name-resolve
[mysqldump]
quick
quote-names
max_allowed_packet = 16M
default-character-set = utf8
[mysql]
[isamchk]
key_buffer = 16M
# Include additional settings
!includedir /etc/mysql/conf.d/
Попробуйте запустить mysqltuner
Может прояснит немного ситуацию. Хотя бы так, для общей картины.
а может быть память жрет memcached? или apache+nginx?
---------- Добавлено 02.12.2015 в 20:27 ----------
тюнер такое выдавал:
>> MySQLTuner 1.4.4 - Major Hayden <major@mhtx.net>
>> Bug reports, feature requests, and downloads at http://mysqltuner.com/
>> Run with '--help' for additional options and output filtering
[OK] Currently running supported MySQL version 5.5.44
[OK] Operating on 64-bit architecture
-------- Storage Engine Statistics -------------------------------------------
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MRG_MYISAM
[--] Data in MyISAM tables: 2M (Tables: 280)
[--] Data in InnoDB tables: 43M (Tables: 857)
[!!] Total fragmented tables: 8
-------- Security Recommendations -------------------------------------------
[OK] There is no anonymous account in all database users
[OK] All database users have passwords assigned
[!!] There is not basic password file list !
-------- Performance Metrics -------------------------------------------------
[--] Up for: 98d 6h 47m 22s (37M q [4.376 qps], 1M conn, TX: 58B, RX: 10B)
[--] Reads / Writes: 36% / 64%
[--] Total buffers: 128.0M global + 4.5M per thread (151 max threads)
[OK] Maximum possible memory usage: 807.5M (78% of installed RAM)
[OK] Slow queries: 0% (1/37M)
[OK] Highest usage of available connections: 30% (46/151)
[OK] Key buffer size / total MyISAM indexes: 16.0M/1.9M
[OK] Key buffer hit rate: 100.0% (6M cached / 2K reads)
[OK] Query cache efficiency: 53.7% (8M cached / 16M selects)
[!!] Query cache prunes per day: 2797
[OK] Sorts requiring temporary tables: 0% (7 temp sorts / 1M sorts)
[!!] Joins performed without indexes: 44151
[!!] Temporary tables created on disk: 41% (231K on disk / 552K total)
[OK] Thread cache hit rate: 99% (46 created / 1M connections)
[!!] Table cache hit rate: 4% (857 open / 19K opened)
[OK] Open file limit used: 0% (0/8K)
[OK] Table locks acquired immediately: 99% (28M immediate / 28M locks)
-------- InnoDB Metrics -----------------------------------------------------
[--] InnoDB is enabled.
[--] InnoDB BufferPool Size :32.0M
[--] InnoDB BufferPool Inst :1
[!!] InnoDB buffer pool / data size: 32.0M/43.5M
[OK] InnoDB buffer pool instances: 1
[OK] InnoDB log waits: 0
-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Enable the slow query log to troubleshoot bad queries
Adjust your join queries to always utilize indexes
When making adjustments, make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries without LIMIT clauses
Increase table_open_cache gradually to avoid file descriptor limits
Read this before increasing table_open_cache over 64: http://*******/1mi7c4C
Variables to adjust:
query_cache_size (> 32M)
join_buffer_size (> 2.0M, or always use indexes with joins)
tmp_table_size (> 32M)
max_heap_table_size (> 32M)
table_open_cache (> 4096)
innodb_buffer_pool_size (>= 43M)
а может быть память жрет memcached? или apache+nginx?
да все может жрать) почему вы только на mysql внимание обратили? проверьте нагрузку командой top, сколько одновременно включенных процессов, будет видно какие и сколько занимают памяти и процессора. сколько у вас в пике посетителей одновременно заходит?
Здравствуйте.
Выбор битрикса - достаточно опрометчивое решение. Он медленный и изменить это весьма трудно. С таким же успехом можно пытаться ускорить другие продукты фирмы 1C.
Могу помочь, но должен заранее предостеречь, что скорость не будет действительно хорошей и размещение будет дорогим. Навскидку стоимость размещения даже под минимальную посещаемость (до 30 запросов страниц в секунду без замедления; от 30 до 100 запросов с замедлением) - от 120 евро в месяц.
Сайт на битриксе.
Сервер:
Процессор 2x2000МГц
Память 2048МБ
Диск: SSD 20Гб
OS centos6-x86_64
Кэш и прочее включено. Пока сайт создавался - работал быстро. Когда зашли 20 сотрудников одновременно - более-менее. Когда выложили в паблике, умер совсем. "WAIT" более 30 секунд от сервера.
Подумал что косяк в сервере, переложил сайт на хостинг VIP-2 от reg ru, стало еще хуже. Конфиг php выбран 5.4_optimized2 (под xCache)
Основной проблемой вижу забитую память, и отсюда проблема выставить нормальное значение для innodb_buffer_pool_size
В каком режиме работает php? Оптимальнее было бы nginx+php-fpm. Можно включить кеширование на уровне nginx, а по факту - меняйте cms :)