Direct Admin i wysokie obciążenie serwera

[ArekJ 0]

Witam.

Strona, która się opiekuję ma serwer VPS z Direct Adminem.

Niestety, jest tam pewien problem z konfiguracją, ponieważ Load Average strasznie skaczę. Przez większość dnia wszystko jest ok, wynosi on od 0,5 do 2, jednak bywają momenty, że skaczę ponad 10, strona zaczyna się zawieszać i ogólnie działać topornie.

 

W Direct Admin pojawiają się logi tego typu:

 

This is an automated message notifying you that the 5 minute load average on your system is 12.25.

This has exceeded the 10 threshold.

One Minute - 8.7

Five Minutes - 12.25

Fifteen Minutes - 12.18

top - 20:50:03 up 3 days, 23:32, 1 user, load average: 8.70, 12.25, 12.18

Tasks: 89 total, 1 running, 86 sleeping, 2 stopped, 0 zombie

%Cpu(s): 22.0 us, 2.4 sy, 0.0 ni, 75.0 id, 0.7 wa, 0.0 hi, 0.0 si, 0.0 st

KiB Mem: 4194304 total, 1820460 used, 2373844 free, 0 buffers

KiB Swap: 2097152 total, 11800 used, 2085352 free, 1820460 cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

12523 admin 20 0 281m 64m 48m S 82.5 1.6 0:08.22 /usr/local/php53/bin/php-cgi53 -d sendmail_from="admin@strona.pl" -d open_basedir="/home/admin/:/tmp:/var/tmp:/usr/local/lib/php/:/usr/local/php53/lib/php/:/usr/local/php53/lib/php/" -d mail.log="/home/admin/.php/php-mail.log"

9548 apache 20 0 457m 11m 3160 S 12.7 0.3 0:02.63 /usr/sbin/httpd -k start -DSSL

12530 admin 20 0 276m 58m 48m S 12.7 1.4 0:06.22 /usr/local/php53/bin/php-cgi53 -d sendmail_from="admin@strona.pl" -d open_basedir="/home/admin/:/tmp:/var/tmp:/usr/local/lib/php/:/usr/local/php53/lib/php/:/usr/local/php53/lib/php/" -d mail.log="/home/admin/.php/php-mail.log"

8589 apache 20 0 521m 12m 3204 S 6.3 0.3 0:05.70 /usr/sbin/httpd -k start -DSSL

12526 admin 20 0 278m 60m 48m S 6.3 1.5 0:09.91 /usr/local/php53/bin/php-cgi53 -d sendmail_from="admin@strona.pl" -d open_basedir="/home/admin/:/tmp:/var/tmp:/usr/local/lib/php/:/usr/local/php53/lib/php/:/usr/local/php53/lib/php/" -d mail.log="/home/admin/.php/php-mail.log"

1 root 20 0 10604 632 600 S 0.0 0.0 0:03.66 init [2]

2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [kthreadd/1683]

3 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [khelper/1683]

1139 root 20 0 71452 3792 2820 S 0.0 0.1 0:00.61 sshd: root@pts/0

1149 root 20 0 17896 2092 1528 S 0.0 0.0 0:00.04 -bash

1475 mail 20 0 45312 680 572 S 0.0 0.0 0:00.16 /usr/sbin/exim -bd -q15m -oP /var/run/exim.pid

1541 root 20 0 23492 1456 1392 S 0.0 0.0 0:00.06 pure-ftpd (SERVER)

1568 root 20 0 47700 2712 980 S 0.0 0.1 0:11.24 /usr/sbin/rsyslogd -c5

1993 root 20 0 1512 80 32 S 0.0 0.0 0:04.32 /usr/local/directadmin/da-popb4smtp

2056 root 20 0 49884 668 556 S 0.0 0.0 0:00.60 /usr/sbin/sshd

3536 root 20 0 4136 728 584 S 0.0 0.0 0:00.03 /bin/sh /usr/local/mysql/bin/mysqld_safe --user=mysql --datadir=/usr/local/mysql/data --pid-file=/usr/local/mysql/data/sever1.pid

3560 root 20 0 14532 656 652 S 0.0 0.0 0:00.00 /sbin/getty 38400 console

3561 root 20 0 14532 660 656 S 0.0 0.0 0:00.00 /sbin/getty 38400 tty2

3566 root 20 0 13748 320 160 S 0.0 0.0 0:13.05 /usr/sbin/apache2 -sn

3634 bind 20 0 120m 3268 1728 S 0.0 0.1 0:01.91 /usr/sbin/named -u bind

4792 mysql 20 0 823m 178m 6420 S 0.0 4.3 1:24.04 /usr/local/mysql/bin/mysqld --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data --plugin-dir=/usr/local/mysql/lib/plugin --user=mysql --log-error=/usr/local/mysql/data/sever1.err --open-files-limit=131070 --pid-file=/usr/local/mysql/data/sever1.pid --port=3306

7348 root 20 0 4136 656 564 T 0.0 0.0 0:00.00 /bin/sh ./install.sh

7359 root 20 0 6392 1028 840 T 0.0 0.0 0:00.00 less

Gdzie admin@strona.pl to oczywiście wartość poprawna. Zmieniłem tutaj, żeby się nigdzie nazwa nie przewinęła publicznie bo wolałbym tego uniknąć.

 

Jak wykryć gdzie jest problem i jemu zaradzić?

Dodam, że w htop przewija się bardzo dużo razy proces /usr/sbin/httpd -k start -DSSL

 

Bardzo proszę o wskazówki.

Pozdrawiam,

Arek

Edytowano Czerwiec 22, 2015 przez ArekJ (zobacz historię edycji)

[Marek607 655]

Zobacz co jest w /home/admin/.php/php-mail.log - jeśli to naparza po cpu to pewnie wysyłka mailingu/spamu, chociaż ciężko cokolwiek na tej podstawie pomóc.

[Misiek08 285]

Strona zaczyna być popularna, a Ty masz serwer z Apache'm i to w niezbyt ciekawej konfiguracji. Nie ma dobrego panelu (inaczej - każdy ma jakieś problemy), który wspiera nginx + php-fpm, więc albo ręcznie to skonfigurujesz albo możesz powoli szukać w Google'u: "jak dokonać cudu, czyli duży ruch na apache".

 

Swoją drogą taki tytuł artykułu dobrze by pozycjonował bloga

[ArekJ 0]

Zobacz co jest w /home/admin/.php/php-mail.log - jeśli to naparza po cpu to pewnie wysyłka mailingu/spamu, chociaż ciężko cokolwiek na tej podstawie pomóc.

Tam są maile wysyłane przez vBulletin, nic innego maili tam nie wysyła. Maile wysyłają się automatycznie po dodanych postach jak ktoś ma włączoną subskrypcję tematu. Wydaje mi się, że to nie powinno generować takiego obciążenia, zresztą jak przyglądam się htop to akurat ten proces nie przekracza zazwyczaj 15%, a Load ciągle skaczę, czasami nawet do 20 mu się zdarza

Strona zaczyna być popularna, a Ty masz serwer z Apache'm i to w niezbyt ciekawej konfiguracji. Nie ma dobrego panelu (inaczej - każdy ma jakieś problemy), który wspiera nginx + php-fpm, więc albo ręcznie to skonfigurujesz albo możesz powoli szukać w Google'u: "jak dokonać cudu, czyli duży ruch na apache".

 

Swoją drogą taki tytuł artykułu dobrze by pozycjonował bloga

Strona cały czas ma zbliżoną ilość odwiedzin, nic się nie zwiększa jak na razie.

 

Jakiś czas temu instalowałem fail2ban, ponieważ była bardzo duża ilość prób logowań do ssh. Może być to powodem? Może przez to wyłączyło się jakieś zabezpieczenie antyDDoS?

 

Co mógłbym jeszcze zamieścić, żeby można było ocenić sytuację?

Edytowano Czerwiec 22, 2015 przez ArekJ (zobacz historię edycji)

[tgx 575]

 

3566 root 20 0 13748 320 160 S 0.0 0.0 0:13.05 /usr/sbin/apache2 -sn

 

Sprawdź co to za proces, nie powinno go tam być jeżeli to DA, sprawdź integralność plików

[Misiek08 285]

To pewnie jakiś zapomniany trup albo próba instalowania czegoś innego przed DA. 0.0 0.0, więc chyba niegroźna sprawa (oczywiście zakładając, że zera nie są tylko na czas tego snapshot'a zrobionego przez DA).

[ArekJ 0]

 

Sprawdź co to za proces, nie powinno go tam być jeżeli to DA, sprawdź integralność plików

Też mi się tak wydaje, ale nie mam pojęcia skąd on się tam bierze.

W /usr/sbin nie ma "apache2". W /etc/init.d też nie ma apache2. W obydwu przypadkach jest tylko httpd

To pewnie jakiś zapomniany trup albo próba instalowania czegoś innego przed DA. 0.0 0.0, więc chyba niegroźna sprawa (oczywiście zakładając, że zera nie są tylko na czas tego snapshot'a zrobionego przez DA).

Tak, te 0 po prostu wiszą. Ten proces nigdy nie "skacze" do góry.

[tgx 575]

ls /proc/PID

 

tam może być coś co nasunie co to jest, może to być jakiś "trup" ale nie uruchomiłby się jednocześnie (bez zmiany portów oczywiście) z tym httpd dostarczanym z DA

 

Nie sądzę, ze to powoduje te loady ale jest dziwne.

 

zainstaluj strace - podepnij się nim do tych procesów na samej górze, trochę długo chodzą jak na utylizację procesora jaką wykazują.

Edytowano Czerwiec 22, 2015 przez tgx (zobacz historię edycji)

[ArekJ 0]

ls /proc/PID

 

tam może być coś co nasunie co to jest, może to być jakiś "trup" ale nie uruchomiłby się jednocześnie (bez zmiany portów oczywiście) z tym httpd dostarczanym z DA

 

Nie sądzę, ze to powoduje te loady ale jest dziwne.

 

zainstaluj strace - podepnij się nim do tych procesów na samej górze, trochę długo chodzą jak na utylizację procesora jaką wykazują.

 

root@sever1:/usr/sbin# ls /proc/3827

auxv cmdline cpuset exe io maps mounts ns oom_score personality schedstat stack status wchan

cgroup comm cwd fd limits mem mountstats numa_maps oom_score_adj root sessionid stat syscall

clear_refs coredump_filter environ fdinfo loginuid mountinfo net oom_adj pagemap sched smaps statm task

Co do strace. Mam wywołać polecenie strace /usr/sbin/httpd i strace /usr/local/php53/bin/php-cgi53 czy chodzi o jakieś inne?

[ArekJ 0]

Dobra, pobawiłem się trochę w detektywa i przy obciążeniu wyłączyłem bazę, Load spadł z ponad 10 do około 5, później wyłączyłem httpd i spadło do okolic 1.

Następnie włączyłem bazę danych i pozostawało w tej okolicy.

Na koniec włączyłem httpd i skoczyło znowu do okolic 10... Czyli jeżeli dobrze kombinuje problem musi leżeć w złej konfiguracji httpd.

Wykonałem polecenie httpd -V

root@sever1:~# httpd -V
[Tue Jun 23 16:35:27.979193 2015] [so:warn] [pid 17612:tid 140236622612224] AH01574: module fcgid_module is already loaded, skipping
Server version: Apache/2.4.12 (Unix)
Server built:   Jun 16 2015 11:43:14
Server's Module Magic Number: 20120211:41
Server loaded:  APR 1.5.1, APR-UTIL 1.5.4
Compiled using: APR 1.5.1, APR-UTIL 1.5.4
Architecture:   64-bit
Server MPM:     worker
  threaded:     yes (fixed thread count)
    forked:     yes (variable process count)
Server compiled with....
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=256
 -D HTTPD_ROOT="/etc/httpd"
 -D SUEXEC_BIN="/usr/sbin/suexec"
 -D DEFAULT_PIDLOG="/var/logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"

i cat /conf/httpd/conf/httpd.conf

 

root@sever1:~# cat /etc/httpd/conf/httpd.conf
#
# This is the main Apache HTTP server configuration file.  It contains the
# configuration directives that give the server its instructions.
# See <URL:http://httpd.apache.org/docs/2.4> for detailed information.
# In particular, see
# <URL:http://httpd.apache.org/docs/2.4/mod/directives.html>
# for a discussion of each configuration directive.
#
# Do NOT simply read the instructions in here without understanding
# what they do.  They're here only as hints or reminders.  If you are unsure
# consult the online docs. You have been warned.


#
# ServerRoot: The top of the directory tree under which the server's
# configuration, error, and log files are kept.
#
# Do not add a slash at the end of the directory path.  If you point
# ServerRoot at a non-local disk, be sure to specify a local disk on the
# Mutex directive, if file-based mutexes are used.  If you wish to share the
# same ServerRoot for multiple httpd daemons, you will need to change at
# least PidFile.
#
ServerRoot "/etc/httpd"


#
# Listen: Allows you to bind Apache to specific IP addresses and/or
# ports, instead of the default. See also the <VirtualHost>
# directive.
#
# Change this to Listen on specific IP addresses as shown below to
# prevent Apache from glomming onto all bound IP addresses.
#
#Listen 12.34.56.78:80


Listen 80


<IfModule unixd_module>
#
# If you wish httpd to run as a different user or group, you must run
# httpd as root initially and it will switch.
#
# User/Group: The name (or #number) of the user/group to run httpd as.
# It is usually good practice to create a dedicated user and group for
# running httpd, as with most system services.
#
User apache
Group apache
</IfModule>


#LoadModule dummy_module /usr/lib/apache/mod_dummy.so
#LoadModule htscanner_module   /usr/lib/apache/mod_htscanner2.so
Include /etc/httpd/conf/extra/httpd-phpmodules.conf
LoadModule fcgid_module /usr/lib/apache/mod_fcgid.so


#
# ServerAdmin: Your address, where problems with the server should be
# e-mailed.  This address appears on some server-generated pages, such
# as error documents.  e.g. admin@your-domain.com
#
ServerAdmin admin@localhost
DocumentRoot "/var/www/html"


<IfModule dir_module>
    DirectoryIndex index.html index.htm index.shtml index.php index.php5 index.php4 index.php3 index.phtml index.cgi
</IfModule>


#
# The following lines prevent .htaccess and .htpasswd files from being
# viewed by Web clients.
#
<Files ".ht*">
    Require all denied
</Files>


#
# The following lines prevent .user.ini files from being viewed by Web clients.
#
<Files ".user.ini">
    Require all denied
</Files>


#
# ErrorLog: The location of the error log file.
# If you do not specify an ErrorLog directive within a <VirtualHost>
# container, error messages relating to that virtual host will be
# logged here.  If you *do* define an error logfile for a <VirtualHost>
# container, that host's errors will be logged there and not here.
#
ErrorLog /var/log/httpd/error_log


#
# LogLevel: Control the number of messages logged to the error_log.
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
#
LogLevel warn


<IfModule log_config_module>
    #replace %b with %O for more accurate logging
    <IfModule mod_logio.c>
      LogFormat "%a %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
      LogFormat "%a %l %u %t \"%r\" %>s %O" common
      LogFormat "%O %I" bytes


      LogFormat "%a %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio
    </IfModule>


    CustomLog /var/log/httpd/access_log common
</IfModule>


<IfModule alias_module>
    # Include some DirectAdmin alias
    Include conf/extra/httpd-alias.conf
</IfModule>


#DefaultType text/plain


<IfModule mime_module>
    TypesConfig conf/mime.types
    AddType application/x-gzip .tgz
    AddEncoding x-compress .Z
    AddEncoding x-gzip .gz .tgz
    AddType application/x-compress .Z
    AddType application/x-gzip .gz .tgz
    AddHandler cgi-script .cgi
    AddHandler type-map var
    AddType text/html .shtml
    AddOutputFilter INCLUDES .shtml
        AddType video/x-ms-asf .avi
        AddType video/mpeg .mpg
        AddType video/mpeg .mpeg
        AddType video/quicktime .mov
        AddType video/x-ms-wmv .wmv
</IfModule>


#
# MaxRanges: Maximum number of Ranges in a request before
# returning the entire resource, or one of the special
# values 'default', 'none' or 'unlimited'.
# Default setting is to accept 200 Ranges.
#MaxRanges unlimited


#
# EnableMMAP and EnableSendfile: On systems that support it,
# memory-mapping or the sendfile syscall may be used to deliver
# files.  This usually improves server performance, but must
# be turned off when serving from networked-mounted
# filesystems or if support for these functions is otherwise
# broken on your system.
# Defaults: EnableMMAP On, EnableSendfile Off
#
#EnableMMAP off
#EnableSendfile off


#######################################################################################
# For user configurations not maintained by DirectAdmin. Empty by default.
#######################################################################################


Include conf/extra/httpd-includes.conf


#######################################################################################
# Supplemental configuration
#######################################################################################


# Options and AllowOverrides
Include conf/extra/httpd-directories.conf


# Nginx reverse proxy configuration
Include conf/extra/httpd-nginx.conf


# Server-pool management (MPM specific)
Include conf/extra/httpd-mpm.conf


# Multi-language error messages
Include conf/extra/httpd-multilang-errordoc.conf


# Fancy directory listings
Include conf/extra/httpd-autoindex.conf


# Language settings
Include conf/extra/httpd-languages.conf


# User home directories
#Include conf/extra/httpd-userdir.conf


# Real-time info on requests and configuration
Include conf/extra/httpd-info.conf


# Suphp
Include conf/extra/httpd-suphp.conf


# Local access to the Apache HTTP Server Manual
#Include conf/extra/httpd-manual.conf


# Distributed authoring and versioning (WebDAV)
Include conf/extra/httpd-dav.conf


# Various default settings
Include conf/extra/httpd-default.conf


# Secure (SSL/TLS) connections
Include conf/extra/httpd-ssl.conf


# Deflate module settings
Include conf/extra/httpd-deflate.conf


#######################################################################################
# Do not change anything in files below, because they are rewritten by DirectAdmin    #
#######################################################################################


# This is needed for PHP
Include conf/extra/httpd-php-handlers.conf


# Virtual hosts
Include conf/extra/httpd-vhosts.conf


# All the DirectAdmin vhosts
Include conf/extra/directadmin-vhosts.conf


#######################################################################################
# End of included files that are rewritten by DirectAdmin                             #
#######################################################################################


<IfModule ssl_module>
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
</IfModule>

 

Podejrzewam, że jest to jakaś standardowa konfiguracja httpd dla DA, ponieważ nikt się tym raczej nie zajmował.

 

Mógłbym prosić o podpowiedź co zrobić, żeby to zaczęło jako tako funkcjonować na httpd? Podejrzewam, że jakby to jakkolwiek skonfigurować to by zaczęło działać, chociaż dopóki storna nie stanie na prostą bo przez to co się dzieje mega spadły odwiedziny, później będzie trzeba przemyśleć nad przeniesieniem tego na jakąś czystą instalajcę, ale póki co wolę tego uniknąć bo to ponad 30GB danych do przeniesienia...

Edytowano Czerwiec 23, 2015 przez ArekJ (zobacz historię edycji)

[behemoth 230]

Lepiej włącz logowanie slow queries.

Logiczne, że skoro wyłączyłeś najpierw mysql, to obciążenie było generowane, ale mniejsze.

Strony statyczne i php bez MySQL'a działało w dalszym ciągu i generowało pewne obciążenie.

Z kolei gdy włączyłeś samego MySQLa, bez httpd, to nie miałeś żadnych zapytań do bazy (chyba, że coś jeszcze łączy się do bazy i ją wykorzystuje?), dlatego nie miało to wpływu na load.

Pozwól MySQLowi trochę podziałać, odpal mysqltunera i zastosuj się do jego podpowiedzi z głową.

[ArekJ 0]

Lepiej włącz logowanie slow queries.

Logiczne, że skoro wyłączyłeś najpierw mysql, to obciążenie było generowane, ale mniejsze.

Strony statyczne i php bez MySQL'a działało w dalszym ciągu i generowało pewne obciążenie.

Z kolei gdy włączyłeś samego MySQLa, bez httpd, to nie miałeś żadnych zapytań do bazy (chyba, że coś jeszcze łączy się do bazy i ją wykorzystuje?), dlatego nie miało to wpływu na load.

Pozwól MySQLowi trochę podziałać, odpal mysqltunera i zastosuj się do jego podpowiedzi z głową.

Okej, tak więc ustawiłem w my.cnf tak:

root@sever1:/usr/mysql# cat /etc/my.cnf
[client]
default-character-set=latin2

[mysqld]
collation-server = latin2_general_ci
init-connect='SET NAMES latin2'
character-set-server = latin2

port            = 3306
local-infile=0
tmpdir=/tmp/

connect_timeout = 5
interactive_timeout = 60
wait_timeout = 600

max_connections = 200
table_open_cache = 4K
max_allowed_packet = 64M
max_heap_table_size = 64M
read_buffer_size = 4M
read_rnd_buffer_size = 16M
sort_buffer_size = 4M
join_buffer_size = 4M
thread_cache_size = 128
thread_concurrency = 8
query_cache_size = 64M
query_cache_limit = 2M
ft_min_word_len = 4
default-storage-engine = MYISAM
thread_stack = 192K
transaction_isolation = REPEATABLE-READ
tmp_table_size = 128M

slow_query_log = ON
long_query_time = 1
slow_query_log_file = "/usr/mysql/slow-log.log"
key_buffer_size = 128M
bulk_insert_buffer_size = 16M
myisam_sort_buffer_size = 64M
myisam_max_sort_file_size = 10G
myisam_repair_threads = 1
myisam_recover

innodb_file_per_table=1
innodb_additional_mem_pool_size = 16M
innodb_buffer_pool_size = 256M
innodb_file_io_threads = 4
innodb_thread_concurrency = 16
innodb_flush_log_at_trx_commit = 1
innodb_log_buffer_size = 8M
innodb_max_dirty_pages_pct = 90
innodb_flush_method=O_DSYNC
innodb_lock_wait_timeout = 120




[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash
default-character-set=latin2

[myisamchk]
key_buffer_size = 512M
sort_buffer_size = 512M
read_buffer = 8M
write_buffer = 8M

[mysqlhotcopy]
interactive-timeout

[mysqld_safe]
open-files-limit = 131070

stworzyłem też plik /usr/mysql/slow-log.log, ale na razie jest pusty jak do tej pory.

Dziwi mnie to, że tak naprawdę nie mogę znaleźć żadnej prawidłowości tego bezndziejnego działania. Np. teraz strona działa świetnie, Load co prawda nadal jest powyżej 2, bo bliżej 3-4, ale nadal to nie jest 15, które było parę minut wcześniej

Edytowano Czerwiec 23, 2015 przez ArekJ (zobacz historię edycji)

[Misiek08 285]

Jaki masz ruch na tej stronie? Jeżeli to jest forum na vB to będziesz miał mega dużo roboty, żeby to działało porządnie na Apache przy poważniejszym ruchu. Jedynie co to aktualizacja do najwyższej wersji i PHP-FPM, ale jak to zrobić na DA to Ci już nie powiem - bo nie wiem.

[ArekJ 0]

Między 100 a 150 użytkowników online na forum, według statystyk vB, ale patrząc po Google Analytics nie przekracza 60.

Dzisiaj np. przez caly dzień było w miarę znośnie, dopiero po 21 skoczyło.

Zoptymalizowałem my.cnf tak jak uważałem, że mogłem sobie na to pozwolić

mysqltuner ma jeszcze z tym problem:

[!!] Temporary tables created on disk: 82% (307 on disk / 371 total)
[...]

Variables to adjust:
    tmp_table_size (> 512M)
    max_heap_table_size (> 64M)

Ale wydaje mi się, że 512 i 64 to i tak sporo...

Znalazłem coś takiego, apropo PHP-FPM, ale to ma 2 lata i wydaje mi się za proste, żeby mogło być tak piękne:

http://help.directadmin.com/item.php?id=459

 

EDIT: Z tego co widzę na serwerze jest zarówno PHP 5.3, które jest wybrane i PHP 5.5, ale nie wiem czy zmiana ma sens. I czy będzie wszystko działało na 5.5. WordPress niby jest w najnowszej wersji, vB też więc niby powinno być ok, ale kto to tam wie...

Edytowano Czerwiec 24, 2015 przez ArekJ (zobacz historię edycji)

[Misiek08 285]

Nie wiem czy nadal ta instrukcja do php-fpm zadziała, możesz spróbować jeżeli masz kopię lub robiłeś już custombuild i wiesz co podawałeś.

 

Pozostałe tryby, w których Apache odpala PHPa są tragiczne przy dzisiejszych skryptach (obciążeniu jakie generują) i w zasadzie tylko oddzielenie PHPa od Apache'a daje jakieś pozytywne rezultaty. Pomijam, że to wciąż Apache.

[mcbarlo 61]

Proponuję jeszcze rzucić okiem na obciążenie operacji i/o. Zerknij iotop-em czy czasem jakiś proces nie zarzyna dysku.

[ArekJ 0]

Proponuję jeszcze rzucić okiem na obciążenie operacji i/o. Zerknij iotop-em czy czasem jakiś proces nie zarzyna dysku.

Chyba strzał w dziesiątkę:

http://zapodaj.net/ab4f86eab9625.png.html

http://zapodaj.net/d3c129414b09f.png.html

http://zapodaj.net/c9c5fe5c4827c.png.html

http://zapodaj.net/dda2705f4d422.png.html

http://zapodaj.net/cede1be6e06da.png.html

http://zapodaj.net/1badd26a0b140.png.html

Szczególnie niepokoi mnie to co dzieje się na 4 screenie.

Te zrzuty wykonałem w przeciągu minuty, góra dwóch. Wydaje mi się, że tak nie powinno być.

Czasami spada do 0 wszystko, a czasami jest tak jak na załączonych obrazkach, a screeny robione są niedługo przed północą, czyli przy mniejszym ruchu.

 

To jest kwestia złej konfiguracji tych procesów jak rozumiem? Czy może coś się dzieje z dyskiem nie tak?

 

Pozdrawiam.

[mcbarlo 61]

Zobacz w logach czy jakiś bot w tym czasie nie skanuje strony.

 

Druga sprawa to, że może być to niezależne od Ciebie, bo ktoś inny na tym samym serwerze fizycznym może swoim VPS-em przeciążać dyski.

[ArekJ 0]

Zobacz w logach czy jakiś bot w tym czasie nie skanuje strony.

 

Druga sprawa to, że może być to niezależne od Ciebie, bo ktoś inny na tym samym serwerze fizycznym może swoim VPS-em przeciążać dyski.

 

Ok, przejrzę logi.

 

Dzisiaj od rana na razie nie obserwuję skoków Loadu i stąd moje pytanie:

Dzisiaj rano na serwerze na którym stoi ten VPS przeprowadzana była akcja serwisowa. Wymieniana była bateria od kontrolera dyskowego.

Od tego czasu mniej więcej jest wszystko dobrze.

 

Możliwe, żeby właśnie to było przyczyną czy to przypadek, że po tym wszystko się uspokoiło?

 

Bo skoro problem jest lub był z IO, czyli z zbyt mocnym obciążeniem dysku, wymieniana była bateria związana z kontrolerem dysków to może to jest/było przyczyną?

[malu 460]

Wymiana baterii jak najbardziej mogłą wprowadzić poprawę w działąniu, bo bez baterii odłączany jest cache od kontrolera. Czyli Twoje problemy z wydajnością I/O były by tutaj jak najbardziej wyjaśnione i też skok loadu serwera, jednak to bardzo słąby wyznacznik, bo mogę CI tak sforkować serwer, że load osiągnie olbrzymie wartości, a serwer będzie nadal responsywny.
U Ciebie najwidoczniej problemem rzeczywiście był wysoki iowait.
Co do wcześniejszych postów, to radziłbym podchodzić do nich bardziej zachowawczo, szczególnie porady @Misiek08 są mocno naciągane, bo z informacji, które podał @ArekJ wynika, że PHP uruchamiane jest na mod_fcgid, który to z reguły działa bardzo dobrze i stabilnie i nie wiem jaką niby przewagę miałby mieć php-fpm nad nim pod względem wydajności interpretowania skryptów PHP?
Podobnie ma się sprawa z nginx, który to nie wprowadzi nam zauważalnej poprawy przy tak znikomym ruchu statycznym.

[ArekJ 0]

Wymiana baterii jak najbardziej mogłą wprowadzić poprawę w działąniu, bo bez baterii odłączany jest cache od kontrolera. Czyli Twoje problemy z wydajnością I/O były by tutaj jak najbardziej wyjaśnione i też skok loadu serwera, jednak to bardzo słąby wyznacznik, bo mogę CI tak sforkować serwer, że load osiągnie olbrzymie wartości, a serwer będzie nadal responsywny.

U Ciebie najwidoczniej problemem rzeczywiście był wysoki iowait.

Co do wcześniejszych postów, to radziłbym podchodzić do nich bardziej zachowawczo, szczególnie porady @Misiek08 są mocno naciągane, bo z informacji, które podał @ArekJ wynika, że PHP uruchamiane jest na mod_fcgid, który to z reguły działa bardzo dobrze i stabilnie i nie wiem jaką niby przewagę miałby mieć php-fpm nad nim pod względem wydajności interpretowania skryptów PHP?

Podobnie ma się sprawa z nginx, który to nie wprowadzi nam zauważalnej poprawy przy tak znikomym ruchu statycznym.

 

 

 

 

Dziękuję za odpowiedź, zresztą to chyba Pan tę wymianę przeprowadzał A na pewno ktoś od Was z firmy bo u Was serwer się znajduje.

 

Do "większych" zmian samodzielnie nie miałem zamiaru się stosować, mógłbym narobić więcej problemów niż pożytku, pewnie wykupilibyśmy usługę z tym związaną.

 

Za to muszę powiedzieć, że optymalizacja bazy danych przy użyciu mysqltunera przyniosła ogromny efekt i strona działa dużo dużo szybciej niż działo się to przed tymi skokami obciążenia.

 

Dzięki wszystkim za pomoc

Edytowano Czerwiec 26, 2015 przez ArekJ (zobacz historię edycji)

[malu 460]

No właśnie coś tak podejrzewałem, że to może być VPS u nas, bo dzisiaj rano wymienialiśmy w jednej platformie baterie i przy okazji dorzuciliśmy dysk SSD na PCI-E, więc w najbliższym czasie uruchomimy tam flashcache, który to powinien jeszcze poprawić wydajność macierzy.

Zmiany czasem są dobre, bo rzeczywiście gdyby tam działało to sobie z jakimś ciężkim wrapperem np. suPHP bez żadnego opcache to zmiana działania PHP mogłaby przynieść różnicę w czasie procesora wykorzystywanym przez intepretator, ale zmiana fastcgi na fastcgi nic nie da.

Edytowano Czerwiec 26, 2015 przez malu (zobacz historię edycji)

[ArekJ 0]

No właśnie coś tak podejrzewałem, że to może być VPS u nas, bo dzisiaj rano wymienialiśmy w jednej platformie baterie i przy okazji dorzuciliśmy dysk SSD na PCI-E, więc w najbliższym czasie uruchomimy tam flashcache, który to powinien jeszcze poprawić wydajność macierzy.

 

Zmiany czasem są dobre, bo rzeczywiście gdyby tam działało to sobie z jakimś ciężkim wrapperem np. suPHP bez żadnego opcache to zmiana działania PHP mogłaby przynieść różnicę w czasie procesora wykorzystywanym przez intepretator, ale zmiana fastcgi na fastcgi nic nie da.

 

Świetna wiadomość!

Im szybciej tym lepiej, ale strona i tak działa w tym momencie naprawdę wydajnie.

Przyznam się szczerze, że jak dostałem wczoraj informację o wymianie tej baterii i sprawdziłem to IO miałem nadzieję, że się poprawi - i na szczęście tak jest, z optymalizacją MySQL przyniosło to świetny efekt.

 

Pozdrawiam!

[ArekJ 0]

 

Im szybciej tym lepiej, ale strona i tak działa w tym momencie naprawdę wydajnie.

 

Przepraszam za post pod postem, ale muszę się odnieść do pogrubionego fragmentu. Chodzi mi oczywiście o im szybsze działanie serwera i strony tym lepiej. W żadnym wypadku nie pośpieszam z wprowadzaniem tych zmian.

 

Ot tak musiałem napisać, bo jakoś nieskładnie to napisałem i wyszło jakbym "poganiał", a chodziło zupełnie o co innego