Высокий iowait

A
На сайте с 03.04.2010
Offline
179
4168

Проблема такова, что большую часть времени высокий %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
png 714ed6418d8f795784e11725ed1bfadd.png
png 991d2c1b2d96cc64d417ad1af767ac18.png
png b0a367e51ea88f20394a92da6dfa6fd5.png
png d0f229cea703a09d3ab4c74f742846bf.png
kxk
На сайте с 30.01.2005
Offline
970
kxk
#1

askary, Буду не оригинален, Nginx стоит?

Ваш DEVOPS
VK
На сайте с 29.12.2011
Offline
42
#2

askary, Вы пытаетесь решить проблему просто отстреливая то, что теоретически может мешать.

Попробуйте сделать иначе - найдите проблему и целенаправленно ее исправьте.

Например какой-нибудь iotop.

По поводу картинок, да, в некоторых случаях это может влиять (например если очень много картинок в одном каталоге). Решение - распределение картинок по каталогам и подкаталогам.

A
На сайте с 03.04.2010
Offline
179
#3
kxk:
askary, Буду не оригинален, Nginx стоит?

да, стоит 10 раз

worker_processes 4;
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)

kxk
На сайте с 30.01.2005
Offline
970
kxk
#4

askary, Скиньте доступы в лс я посмотрю

---------- Добавлено 26.07.2014 в 16:19 ----------

V2NEK, А, про кеширование картинок на стороне Nginx - нет не слышал:)

Не всегда возможно изменить логику приложения, я бы сказал невозможно в 98% случаев.

---------- Добавлено 26.07.2014 в 16:21 ----------

askary, У вас OpenVZ впс или сам сервер под 1 контейнер?

Просто по памяти это ядро OpenVZ (Гугль подтвердил что мне пока не стоит идти до невропатолога).

A
На сайте с 03.04.2010
Offline
179
#5
сам сервер под 1 контейнер

kxk, да, у меня впс занимает все ресурсы сервера (при переезде так оставили). Доступы скинул, может вы что-то придумаете

K5
На сайте с 21.07.2010
Offline
209
#6
MaxSpareServers 6
ServerLimit 50
MaxClients 50

зачем так жестко???

25

100

100

max_connections = 120

хотя бы

query_cache_size = 768M

много, рыться по такому кешу серверу тоже не очень приятно

256 мах

query_cache_limit = 1M

аська 45два48499два записки на работе (http://memoryhigh.ru) помогу с сайтом, удалю вирусы, настрою впс -> отзывы ТУТ (/ru/forum/836248) и ТАМ (http://www.maultalk.com/topic140187.html) !!!всегда проверяйте данные людей, которые сами пишут вам в аську или скайп!!!
A
На сайте с 03.04.2010
Offline
179
#7

посмотрел kxk, вроде проблема была в активности логописания, понаблюдаю до завтра, надеюсь отключение логов решит проблему

---------- Добавлено 26.07.2014 в 16:18 ----------

kgtu5:
зачем так жестко???
25
100
100
max_connections = 120
хотя бы

а их много надо при живом нгинксе?

lealhost
На сайте с 07.06.2014
Offline
136
#8
askary:
посмотрел kxk, вроде проблема была в активности логописания, понаблюдаю до завтра, надеюсь отключение логов решит проблему

а их много надо при живом нгинксе?

Не отключайте логи, буферизацию для них включите :)

Как уже советовали выше, воспользуйтесь iotop.

A
На сайте с 03.04.2010
Offline
179
#9
lealhost:
Не отключайте логи, буферизацию для них включите :)

ну пока посмотрим в них ли была причина, а потом уже будем думать дальше

---------- Добавлено 26.07.2014 в 16:24 ----------

kgtu5:

query_cache_limit = 1M

обоснуйте.......

K5
На сайте с 21.07.2010
Offline
209
#10
обоснуйте.......

у вас сложные выборки из милионов записей?

подумайте на сколько легко потом серверу искать в кеше такой же запрос сравнивая 8мб кода с 700мб закешированных

---------- Добавлено 26.07.2014 в 17:31 ----------

отключать логи есть плохо

---------- Добавлено 26.07.2014 в 17:33 ----------

нгикс только статику обрабатывает, а пхп - апач за ним и их всего 6, при нормальной посещаемости они все время в работе без передыху да еще и очередь на обработку в километр))

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий