- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Проблема такова, что большую часть времени высокий %wa и все тормозит жутко. пробовал шаманить по всякому с настройками но чет не помогало, поудалял тяжелые плагины с сайтов - тоже самое. Скорость диска вроде норм(когда нет нагрузки), смарт тоже в порядке. Пики нагрузки это когда боты бирж приходят. Но даже без них %wa держится на уровне 10. И на сайтах много картинок, но не уверен может ли это влиять на нагрузку которую создают боты бирж.
core i3 8gb 500gb sata
И ещё, не может ли это быть следствием косяка ядра или сервиса какого-то? (Linux 2.6.32-042stab088.4)
innodb_buffer_pool_size = 250M
max_connections = 90
open_files_limit = 20000
local-infile = 0
skip-name-resolve
key_buffer_size = 650M
read_buffer_size = 2M
read_rnd_buffer_size = 2M
join_buffer_size = 4M
sort_buffer_size = 2M
query_cache_type = 1
query_cache_size = 768M
query_cache_limit = 8M
max_write_lock_count = 1
max_allowed_packet = 64M
table_cache = 8192
table_definition_cache = 8192
thread_cache = 32
net_buffer_length = 16k
myisam-recover = FORCE
wait_timeout = 20
interactive_timeout = 20
connect_timeout = 30
query_cache_wlock_invalidate
max_tmp_tables = 64
bulk_insert_buffer_size = 64M
tmp_table_size = 256M
max_heap_table_size = 256M
preload_buffer_size = 1M
myisam_sort_buffer_size = 512M
memlock
low_priority_updates
tmpdir = /tmp/mysqltmp
<IfModule prefork.c>
StartServers 2
MinSpareServers 2
MaxSpareServers 6
ServerLimit 50
MaxClients 50
MaxRequestsPerChild 3000
</IfModule>
FcgidIOTimeout 60
FcgidMaxRequestsPerProcess 3000
FcgidMaxProcesses 250
FcgidMinProcessesPerClass 1
FcgidMaxProcessesPerClass 30
FcgidIdleTimeout 60
FcgidIdleScanInterval 10
FcgidBusyTimeout 60
FcgidBusyScanInterval 60
FcgidMaxRequestLen 15737418
askary, Буду не оригинален, Nginx стоит?
askary, Вы пытаетесь решить проблему просто отстреливая то, что теоретически может мешать.
Попробуйте сделать иначе - найдите проблему и целенаправленно ее исправьте.
Например какой-нибудь iotop.
По поводу картинок, да, в некоторых случаях это может влиять (например если очень много картинок в одном каталоге). Решение - распределение картинок по каталогам и подкаталогам.
askary, Буду не оригинален, Nginx стоит?
да, стоит 10 раз
worker_rlimit_nofile 20000;
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;
---------- Добавлено 26.07.2014 в 14:30 ----------
V2NEK, хз даже куда копать, уже пару админов смотрели, и безрезультатно.
И ещё, не может ли это быть следствием косяка ядра или сервиса какого-то? (Linux 2.6.32-042stab088.4)
askary, Скиньте доступы в лс я посмотрю
---------- Добавлено 26.07.2014 в 16:19 ----------
V2NEK, А, про кеширование картинок на стороне Nginx - нет не слышал:)
Не всегда возможно изменить логику приложения, я бы сказал невозможно в 98% случаев.
---------- Добавлено 26.07.2014 в 16:21 ----------
askary, У вас OpenVZ впс или сам сервер под 1 контейнер?
Просто по памяти это ядро OpenVZ (Гугль подтвердил что мне пока не стоит идти до невропатолога).
kxk, да, у меня впс занимает все ресурсы сервера (при переезде так оставили). Доступы скинул, может вы что-то придумаете
ServerLimit 50
MaxClients 50
зачем так жестко???
25
100
100
max_connections = 120
хотя бы
много, рыться по такому кешу серверу тоже не очень приятно
256 мах
query_cache_limit = 1M
посмотрел kxk, вроде проблема была в активности логописания, понаблюдаю до завтра, надеюсь отключение логов решит проблему
---------- Добавлено 26.07.2014 в 16:18 ----------
зачем так жестко???
25
100
100
max_connections = 120
хотя бы
а их много надо при живом нгинксе?
посмотрел kxk, вроде проблема была в активности логописания, понаблюдаю до завтра, надеюсь отключение логов решит проблему
а их много надо при живом нгинксе?
Не отключайте логи, буферизацию для них включите :)
Как уже советовали выше, воспользуйтесь iotop.
Не отключайте логи, буферизацию для них включите :)
ну пока посмотрим в них ли была причина, а потом уже будем думать дальше
---------- Добавлено 26.07.2014 в 16:24 ----------
query_cache_limit = 1M
обоснуйте.......
у вас сложные выборки из милионов записей?
подумайте на сколько легко потом серверу искать в кеше такой же запрос сравнивая 8мб кода с 700мб закешированных
---------- Добавлено 26.07.2014 в 17:31 ----------
отключать логи есть плохо
---------- Добавлено 26.07.2014 в 17:33 ----------
нгикс только статику обрабатывает, а пхп - апач за ним и их всего 6, при нормальной посещаемости они все время в работе без передыху да еще и очередь на обработку в километр))