- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Привет,
Tasks: 468 total, 2 running, 466 sleeping, 0 stopped, 0 zombie
Cpu(s): 14.4%us, 1.7%sy, 0.0%ni, 58.6%id, 24.9%wa, 0.2%hi, 0.2%si, 0.0%st
Mem: 12330792k total, 12049108k used, 281684k free, 2165208k buffers
Swap: 4200888k total, 59552k used, 4141336k free, 4148552k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11612 mysql 20 0 4660m 751m 5920 S 105 6.2 149962:50 mysqld
3441 www-data 20 0 348m 18m 7376 S 1 0.1 0:00.08 apache2
3371 www-data 20 0 347m 20m 8656 S 1 0.2 0:00.22 apache2
3385 www-data 20 0 349m 19m 8852 S 1 0.2 0:00.22 apache2
3442 www-data 20 0 351m 17m 6572 D 1 0.1 0:00.04 apache2
18920 root 15 -5 0 0 0 S 1 0.0 194:54.39 kondemand/0
3 root RT -5 0 0 0 S 0 0.0 45:01.44 migration/0
1 root 20 0 10520 688 640 S 0 0.0 1:08.50 init
2 root 15 -5 0 0 0 S 0 0.0 0:00.16 kthreadd
4 root 15 -5 0 0 0 S 0 0.0 1:52.31 ksoftirqd/0
5 root RT -5 0 0 0 S 0 0.0 0:21.20 watchdog/0
6 root RT -5 0 0 0 S 0 0.0 10:59.68 migration/1
7 root 15 -5 0 0 0 S 0 0.0 0:11.14 ksoftirqd/1
8 root RT -5 0 0 0 S 0 0.0 0:00.06 watchdog/1
9 root RT -5 0 0 0 S 0 0.0 67:11.59 migration/2
10 root 15 -5 0 0 0 S 0 0.0 0:34.45 ksoftirqd/2
11 root RT -5 0 0 0 S 0 0.0 0:00.26 watchdog/2
явные проблемы есть? и можете подсказать как исправить?
LA ~ 7 не такой уж и высокий.
Если раньше не оптимизировали mysql - можете сделать это. Самый просто способ - прогнать mysqltuner`ом, он подскажет вам значения.
LA ~ 7 не такой уж и высокий.
Если раньше не оптимизировали mysql - можете сделать это. Самый просто способ - прогнать mysqltuner`ом, он подскажет вам значения.
да не высокий, но он иногда по неизвестным причинам резко подскакивает до 60, прогонял:
[--] Status: +Archive -BDB -Federated -InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 1G (Tables: 2924)
[--] Data in MEMORY tables: 3M (Tables: 4)
[!!] Total fragmented tables: 99
-------- Performance Metrics -------------------------------------------------
[--] Up for: 131d 21h 13m 9s (16B q [1K qps], 152M conn, TX: 19733B, RX: 1605B)
[--] Reads / Writes: 98% / 2%
[--] Total buffers: 522.0M global + 136.1M per thread (2000 max threads)
[!!] Maximum possible memory usage: 266.4G (2265% of installed RAM)
[OK] Slow queries: 0% (219K/16B)
[OK] Highest usage of available connections: 31% (632/2000)
[OK] Key buffer size / total MyISAM indexes: 256.0M/701.8M
[OK] Key buffer hit rate: 99.9% (416B cached / 346M reads)
[OK] Query cache efficiency: 83.3% (13B cached / 15B selects)
[!!] Query cache prunes per day: 14245463
[OK] Sorts requiring temporary tables: 0% (7K temp sorts / 239M sorts)
[!!] Joins performed without indexes: 70286616
[!!] Temporary tables created on disk: 47% (151M on disk / 320M total)
[OK] Thread cache hit rate: 98% (1M created / 152M connections)
[!!] Table cache hit rate: 4% (7K open / 169K opened)
[OK] Open file limit used: 45% (9K/22K)
[OK] Table locks acquired immediately: 99% (4B immediate / 4B locks)
-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Reduce your overall MySQL memory footprint for system stability
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_cache gradually to avoid file descriptor limits
Variables to adjust:
*** MySQL's maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***
query_cache_size (> 128M)
join_buffer_size (> 128.0M, or always use indexes with joins)
tmp_table_size (> 128M)
max_heap_table_size (> 256M)
table_cache (> 10000)
my.cnf
skip-innodb
key_buffer = 256M
table_cache = 10000
sort_buffer_size = 4M
read_buffer_size = 2M
read_rnd_buffer_size = 2M
net_buffer_length = 2K
thread_stack = 128K
thread_cache_size = 8
query_cache_type=1
query_cache_size=128M
open_files_limit = 7000
tmp_table_size = 128M
max_heap_table_size = 256M
join_buffer_size = 128M
max_connections=1000 - здесь ранее до теста было 2000
log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 2
[!!] Maximum possible memory usage: 266.4G (2265% of installed RAM)
У вас нет столько оперативки. И даже если вы поставите max_connections=1000 - все равно не хватит. С таким конфигом сервер будет работать нестабильно.
Или сделайте нормальный конфиг, исходя из конфига вашей впски. Или же возьмите впску или выделенный сервер с большим объемом оперативки.
max_connections - в любом случае вам не нужно делать больше 650(но опять же у вас нет столько оперативки).
вашей впски. Или же возьмите впску или выделенный сервер с большим объемом оперативки.
у меня вообще-то выделенный сервер и 12 гб оперативки, неужели из-за настроек мускуля так может работать сервер?
а если в реалтайме 2000 человек?
а если в реалтайме 2000 человек?
Ну они же не одновременно.
Поднимайте значения в конфиге. Начинайте с:
query_cache_size=1024M
join_buffer_size=512M
tmp_table_size=384M
А вообще, смотрите в сторону ускорения дисковой подсистемы. Крайне рекомендую flashcache. Про проблемы производительности забудете надолго.
а если в реалтайме 2000 человек?
То с такими настройками может не хватить памяти. И это будет намного грустнее чем нехватка подключений к мускулу.
Сделайте join_buffer_size = 2M
Снизится > потребление для ?M per thread
Key buffer size / total MyISAM indexes: 256.0M/701.8M
Увеличьте key_buffer = 1G
max_connections=1000
---------- Добавлено 05.07.2012 в 22:53 ----------
а если в реалтайме 2000 человек?
У вас пик - 632 был
Поднимайте значения в конфиге. Начинайте с:
query_cache_size=1024M
join_buffer_size=512M
tmp_table_size=384M
Вы это серьезно?
Т.е. вот это никого не беспокоит?
[!!] Temporary tables created on disk: 47% (151M on disk / 320M total)
Второе может являться следствием первого, при том, что tmp_table_size = 128M. Для начала почитайте mysql-slow.log и делайте explain долгим запросам с join'ами.