Jumlah anak-anak dikendalikan oleh arahan konfigurasi manajer proses dalam file konfigurasi kumpulan. Saya kira pengaturan saat ini adalah Untuk mencapai ini, edit file konfigurasi kumpulan dan atur Catatan: Saran ini didasarkan pada pengalaman saya dengan Debian 7, tetapi harus berlaku juga untuk Ubuntu. Jika mencari cara untuk pengaturan PHP-FPM, pasti menemukan konfirguasi yang gitu-gitu aja. Mereka semua menggunakan Proses Manager (PM) dengan mode Dynamic dan memiliki satu proses utama untuk menjalankannya. Sebetulnya tidak ada yang salah dengan itu, namun ada cara yang lebih mantap. Bagaimanakah caranya? mari kita simak selengkapnya. Why ‘dynamic’ should
not be your default process manager Why you should prefer the ‘ondemand’ Process Manager instead of ‘dynamic’ [pool_name] ... pm = dynamic pm.max_children = 5 pm.start_servers = 3 pm.min_spare_servers = 2 pm.max_spare_servers = 4 pm.max_requests = 200 Most “guides” advocate the use of the ‘dynamic’ Process Manager (‘pm’ option in the config), which allows you to choose how many minimum and maximum (spare) processes you have per pool. Many guides however make blind assumptions on what your server specs are and will cause, like in the example above, a minimum of 3 PHP processes running per pool (pm.start_servers = 3). If you’re on a low-traffic site, that could very well be overkill. For your server, it looks like this in your processlist. root 3986 4704 ? Ss 19:04 php-fpm: master process (/etc/php-fpm.conf) user 3987 4504 ? S 19:04 \_ php-fpm: pool pool_name user 3987 4504 ? S 19:04 \_ php-fpm: pool pool_name user 3987 4504 ? 19:04 \_ php-fpm: pool pool_name Ke-3 proses ini pasti akan selalu berjalan, meskipun mereka dibutuhkan ataupun tidak. Menggunakan Ondemand Process ManagerA far better way to run PHP-FPM pools, but badly documented, would be the ‘ondemand’ Process Manager. As the name suggests, it does not leave processes lingering, but spawns them as they are needed. The configuration is similar to the above, but simplified. [pool_name] ... pm = ondemand pm.max_children = 5 pm.process_idle_timeout = 10s pm.max_requests = 200 The ‘ondemand’ process manager was added since PHP 5.3.8. The config above causes your default processlist to look like this. root 3986 4704 ? Ss 19:04 php-fpm: master process (/etc/php-fpm.conf) Only the master process is spawned, there are no pre-forked PHP-FPM processes. Only when processes are needed will they be started, to a maximum of 5 (with the config above, which is defined by pm.max_children). So if there are 2 simultaneous PHP requests going on, the processlist would be: root 3986 4704 ? Ss 19:04 php-fpm: master process (/etc/php-fpm.conf) user 3987 4504 ? S 19:04 \_ php-fpm: pool pool_name user 3987 4504 ? S 19:04 \_ php-fpm: pool pool_name After the configured timeout in “pm.process_idle_timeout”, the process will be stopped again. This does not impact PHP’s max_execution_time, because the process manager only considers a process “idle” when it’s not serving any request. If you’re working on a high performance PHP setup, the ‘ondemand’ PM may not be for you. In that case, it’s wise to pre-fork your PHP-FPM processes up to the maximum your server can handle. That way, all your processes are ready to serve your requests without needing to be spawned first. However, for 90% of the sites out there, the ondemand PHP-FPM configuration is better than either static or dynamic. A shared APC or OPcache: why multiple PHP-FPM masters are better That inherently means that the APC/OPcache cache is shared between all PHP-FPM pools. If you only have a single site to serve, that’s no issue. If you have a few dozen sites on the same server via PHP-FPM, you should be aware that they all share the same APC/OPcache cache. The APC or OPcache size should then be big enough to hold the opcode cache of all your sites combined. To avoid this, each PHP-FPM pool can also be started separately and have it’s own master process. That means each site can have its own APC or OPcache and can be started/stopped independently from all the other PHP-FPM pools. A change in one pool’s config does not cause all the other FPM pools to be reloaded when the new config needs to be activated, which is the default behaviour of “/etc/init.d/php-fpm reload” (it would reload all pools). What’s needed to achieve this then;Each PHP-FPM pool needs its own init.d start/stop script Looking at the
PHP-FPM configuration $ cat /etc/php-fpm.d/pool1.conf [global] pid = /var/run/php-fpm/pool1.pid log_level = notice emergency_restart_threshold = 0 emergency_restart_interval = 0 process_control_timeout = 0 daemonize = yes [pool1] listen = /var/run/php-fpm/pool1.sock listen.owner = pool1 listen.group = pool1 listen.mode = 0666 user = pool1 group = pool1 pm = ondemand pm.max_children = 5 pm.process_idle_timeout = 10s pm.max_requests = 500 The above contains the most important bits; the main config determines that it can be daemonized and where the PID-file should be located. The Pool-configuration has the basic information of where to listen to and the type of Process Manager. The init.d file is a simple copy/paste from the default /etc/init.d/php-fpm with a few modifications. $ cat /etc/init.d/php-fpm-pool1 #! /bin/sh # # chkconfig: - 84 16 # description: PHP FastCGI Process Manager for pool 'pool1' # processname: php-fpm-pool1 # config: /etc/php-fpm.d/pool1.conf # pidfile: /var/run/php-fpm/pool1.pid # Standard LSB functions #. /lib/lsb/init-functions # Source function library. . /etc/init.d/functions # Check that networking is up. . /etc/sysconfig/network if [ "$NETWORKING" = "no" ] then exit 0 fi RETVAL=0 prog="php-fpm-pool1" pidfile=/var/run/php-fpm/pool1.pid lockfile=/var/lock/subsys/php-fpm-pool1 fpmconfig=/etc/php-fpm.d/pool1 start () { echo -n $"Starting $prog: " daemon --pidfile ${pidfile} php-fpm --fpm-config=${fpmconfig} --daemonize RETVAL=$? echo [ $RETVAL -eq 0 ] && touch ${lockfile} } stop () { echo -n $"Stopping $prog: " killproc -p ${pidfile} php-fpm RETVAL=$? echo if [ $RETVAL -eq 0 ] ; then rm -f ${lockfile} ${pidfile} fi } restart () { stop start } reload () { echo -n $"Reloading $prog: " killproc -p ${pidfile} php-fpm -USR2 RETVAL=$? echo } # See how we were called. case "$1" in start) start ;; stop) stop ;; status) status -p ${pidfile} php-fpm RETVAL=$? ;; restart) restart ;; reload|force-reload) reload ;; condrestart|try-restart) [ -f ${lockfile} ] && restart || : ;; *) echo $"Usage: $0 {start|stop|status|restart|reload|force-reload|condrestart|try-restart}" RETVAL=2 ;; esac exit $RETVAL The only pieces we changed to that init.d script are at the top; a new process name has been defined (this needs to be unique) and the PID-file has been changed to point to our custom PID-file for this pool, as it’s defined in the pool1.conf file above. You can now start/stop this pool separately from all the others. It’s configuration can be changed without impacting others. If you have multiple pools configured, your process list would look like this. root 5963 4704 ? Ss 19:23 0:00 php-fpm: master process (/etc/php-fpm.d/pool1.conf) root 6036 4744 ? Ss 19:23 0:00 php-fpm: master process (/etc/php-fpm.d/pool2.conf) Multiple master processes are running as root and are listening to a socket defined in the pool configuration. As soon as PHP requests are made, they spawn children to handle them and stop them again after 10s of idling. The master process also shows which configuration file it loaded, making it easy to pinpoint the configuration of that particular pool. Pemisahan ProsesAs soon as PHP requests are made, the processlist looks like this. root 5963 4704 Ss 19:23 php-fpm: master process (/etc/php-fpm.d/p1.conf) user 3987 4504 S 19:23 \_ php-fpm: pool pool1 user 3987 4504 S 19:23 \_ php-fpm: pool pool1 root 6036 4744 Ss 19:23 php-fpm: master process (/etc/php-fpm.d/p2.conf) user 3987 4504 S 19:23 \_ php-fpm: pool pool2 To summarise, the above has 2 main advantages: a separate APC/OPcache bytecode cache per PHP-FPM pool Things to keep in mind when doing this: Logrotate should be modified if you use error logging in each FPM pool, to use the correct pool’s PID to reload the master process; Demikian. Semoga membantu. Dilihat: 1.039 |