- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Подскажите правильно ли настроил, что подкрутить может ещё? Сервер: core i3, 8gb, 500gb. Сайты в основном вп и джумла.
/etc/httpd/conf/httpd.conf
KeepAlive On
MaxKeepAliveRequests 75
KeepAliveTimeout 5
<IfModule prefork.c>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
ServerLimit 256
MaxClients 256
MaxRequestsPerChild 10000
</IfModule>
/etc/httpd/conf.d/fcgid.conf
FcgidMaxRequestsPerProcess 5000
FcgidMaxProcesses 500
FcgidMinProcessesPerClass 1
FcgidMaxProcessesPerClass 50
FcgidIdleTimeout 60
FcgidIdleScanInterval 10
FcgidBusyTimeout 60
FcgidBusyScanInterval 30
FcgidMaxRequestLen 9992428800
/etc/nginx/nginx.conf
worker_rlimit_nofile 100000;
worker_connections 8192;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
server_tokens off;
gzip on;
gzip_static on;
gzip_comp_level 5;
gzip_min_length 1024;
keepalive_timeout 15;
log_not_found off;
proxy_read_timeout 30;
proxy_send_timeout 30;
client_max_body_size 60m;
mysqltuner выдал
[--] Up for: 9d 21h 36m 1s (323M q [378.771 qps], 1M conn, TX: 1492B, RX: 97B)
[--] Reads / Writes: 95% / 5%
[--] Total buffers: 1.9G global + 8.2M per thread (151 max threads)
[OK] Maximum possible memory usage: 3.1G (38% of installed RAM)
[OK] Slow queries: 0% (9K/323M)
[OK] Highest usage of available connections: 47% (72/151)
[OK] Key buffer size / total MyISAM indexes: 1.0G/537.9M
[OK] Key buffer hit rate: 99.9% (33B cached / 32M reads)
[OK] Query cache efficiency: 60.8% (187M cached / 309M selects)
[!!] Query cache prunes per day: 5274374
[OK] Sorts requiring temporary tables: 0% (492 temp sorts / 15M sorts)
[!!] Joins performed without indexes: 65527
[!!] Temporary tables created on disk: 26% (2M on disk / 9M total)
[OK] Thread cache hit rate: 99% (7K created / 1M connections)
[!!] Table cache hit rate: 0% (1K open / 4M opened)
[!!] Open file limit used: 88% (1K/2K)
[OK] Table locks acquired immediately: 99% (151M immediate / 152M locks)
[OK] InnoDB data size / buffer pool: 151.7M/256.0M
-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Enable the slow query log to troubleshoot bad queries
Increasing the query_cache size over 128M may reduce performance
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:
query_cache_size (> 512M) [see warning above]
join_buffer_size (> 2.0M, or always use indexes with joins)
tmp_table_size (> 128M)
max_heap_table_size (> 128M)
table_cache (> 1024)
open_files_limit (> 2209)
/etc/my.conf
local-infile=0
skip-name-resolve
key_buffer_size = 1024M
read_buffer_size=2M
read_rnd_buffer_size=2M
join_buffer_size=1M
sort_buffer_size=2M
low_priority_updates
query_cache_type = 1
query_cache_size = 256M
query_cache_limit = 8M
max_write_lock_count=1
max_allowed_packet = 64M
table_cache = 512
thread_cache = 16
net_buffer_length=16k
myisam-recover=FORCE
wait_timeout=120
interactive_timeout=120
connect_timeout=120
query_cache_wlock_invalidate
max_tmp_tables=128
bulk_insert_buffer_size=64M
tmp_table_size=64M
max_heap_table_size=64M
preload_buffer_size=1M
myisam_sort_buffer_size=64M
memlock
тюнер же написал
max_heap_table_size (> 128M)
table_cache (> 1024)
open_files_limit (> 2209)
читали предупреждение ниже?
вряд ли у всех ваших баз есть столько
gzip нгиксу пока вряд ли нужен
ну и фронтенд у вас ждет ответа 30 сек, а бекенд может работать 60 сек = периодическая 504 ошибка обеспечена
тюнер же написал
читали предупреждение ниже?
так я и сделал как тюнер просил, уменьшил в 2 раза
gzip нгиксу пока вряд ли нужен
а почему не нужен?
вес всех баз 5гб
кого уменьшил??????????
вообще то знак > обозначает больше чем указанное число
но не ключей, их всего 537.9M
как-то нелогично тогда
Increasing the query_cache size over 128M may reduce performance
query_cache_size (> 512M) [see warning above]
Покажите графики munin
как-то нелогично тогда
Increasing the query_cache size over 128M may reduce performance
query_cache_size (> 512M) [see warning above]
вполне логично - при любом запросе к базе нужно сначала проверить 128Мб+++ кешированных запросов на совпадение с текущим и только после обработать
Покажите графики munin
сорри, такого нет. ну мне особого анализа не нужно, так только что бы настройки оптимально соответствовали конфигурации сервера
mysql подкрутил как тюнер просил(через сутки снова прогоню)
---------- Добавлено 08.05.2014 в 18:39 ----------
KeepAliveTimeout(httpd) должен равняться keepalive_timeout(nginx) ?
KeepAliveTimeout(httpd) должен равняться keepalive_timeout(nginx) ?
Нет. На httpd KeepAlive лучше выключить.
Не думаю что сервер с WP/Joomla сколько процессов переварит.
---------- Добавлено 08.05.2014 в 20:28 ----------
Nginx не даст вам столько.
сорри, такого нет. ну мне особого анализа не нужно, так только что бы настройки оптимально соответствовали конфигурации сервера
Без анализа, вы ничего не сможете оптимизировать, ведь что бы понять, почему машина плохо едет, надо понять какой агрегат не работает, и почему он тормозит работу.
Я когда-то поднимал тему с анализом происходящего:
/ru/forum/772094 попробуйте изъять оттуда полезные для себя моменты, я уже проводил краткий анализ с помощью графиков и других посетителей SE.
Понимаете какая тут штука тонкая, можно сегодня нанять 20 специалистов, потратить пару дней времени и сделать все супер оптимально, но завтра на каких-то сайтах изменяться темпы роста базы, интенсивность запросов, их объем, а так же объем получаемых ответов и все оптимизации "пойдут лесом" , причем сразу.... по этому оптимизация проводится под конкретными условиями... т.е вы четко должны понимать , что вы хотите оптимизировать, а запросы "оптимизировать mysql под сайт" это ...... сильно уж безграмотно... (ничего личного).