首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >php无法处理并发连接

php无法处理并发连接
EN

Server Fault用户
提问于 2019-07-19 14:03:20
回答 1查看 2.9K关注 0票数 2

我正在处理一个问题,一个拥有94 24和24个CPU核心的服务器无法处理40个并发连接。使用ab工具,我发送了40个请求,每次都发送:

代码语言:javascript
复制
ab -n 40 -c 40 http://ip-address/

第一个请求完成得很快:

代码语言:javascript
复制
Concurrency Level:      40
Time taken for tests:   1.951 seconds
Complete requests:      40
Failed requests:        0
Non-2xx responses:      40
Total transferred:      20280 bytes
HTML transferred:       0 bytes
Requests per second:    20.50 [#/sec] (mean)
Time per request:       1951.311 [ms] (mean)
Time per request:       48.783 [ms] (mean, across all concurrent requests)
Transfer rate:          10.15 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       27   73  28.7     75     120
Processing:   540 1008 129.6    998    1256
Waiting:      536 1007 129.9    998    1255
Total:        575 1081 153.1   1071    1376

Percentage of the requests served within a certain time (ms)
  50%   1071
  66%   1177
  75%   1208
  80%   1237
  90%   1261
  95%   1322
  98%   1376
  99%   1376
 100%   1376 (longest request)

但是,再次运行相同的命令将导致连接超时。在接下来的几分钟内,我将无法进入服务器。

我发送请求的页面执行760个查询,其中包括748个SELECT查询。我将MariaDB max_connections设置为500,这是PHP池配置:

代码语言:javascript
复制
listen = 127.0.0.1:9000
listen.allowed_clients = 127.0.0.1
listen.owner = nginx
listen.group = nginx
listen.mode = 0660
user = xxxx ; modified
group = xxxx ; modified
pm = ondemand
pm.max_children = 1000
pm.start_servers = 200
pm.min_spare_servers = 50
pm.max_spare_servers = 100
pm.max_requests = 500
request_terminate_timeout = 100s
pm.process_idle_timeout = 3s
php_admin_value[error_log] = /var/log/php-fpm/pool-error.log
php_admin_flag[log_errors] = on
php_value[session.save_handler] = files
php_value[session.save_path] = /var/lib/php/session

我将pm设置为ondemand,因此我认为max_children将不再适用。

我也很难与SELinux一起工作。会不会是罪魁祸首?

更新

mysqltuner.pl的输出:

代码语言:javascript
复制
Currently running supported MySQL version 10.4.6-MariaDB
[OK] Operating on 64-bit architecture

-------- Log file Recommendations ------------------------------------------------------------------
[--] Log file: /var/lib/mysql/localhost.localdomain.err(0B)
[!!] Log file /var/lib/mysql/localhost.localdomain.err doesn't exist
[!!] Log file /var/lib/mysql/localhost.localdomain.err isn't readable.

-------- Storage Engine Statistics -----------------------------------------------------------------
[--] Status: +Aria +CSV +InnoDB +MEMORY +MRG_MyISAM +MyISAM +PERFORMANCE_SCHEMA +SEQUENCE 
[--] Data in MyISAM tables: 72.0K (Tables: 12)
[--] Data in InnoDB tables: 1.9G (Tables: 449)
[--] Data in MEMORY tables: 0B (Tables: 17)
[OK] Total fragmented tables: 0

-------- Analysis Performance Metrics --------------------------------------------------------------
[--] innodb_stats_on_metadata: OFF
[OK] No stat updates during querying INFORMATION_SCHEMA.

-------- Security Recommendations ------------------------------------------------------------------
[OK] There are no anonymous accounts for any database users
[OK] All database users have passwords assigned
[!!] There is no basic password file list!

-------- CVE Security Recommendations --------------------------------------------------------------
[--] Skipped due to --cvefile option undefined

-------- Performance Metrics -----------------------------------------------------------------------
[--] Up for: 3m 0s (15K q [85.489 qps], 401 conn, TX: 44M, RX: 4M)
[--] Reads / Writes: 99% / 1%
[--] Binary logging is disabled
[--] Physical Memory     : 94.2G
[--] Max MySQL memory    : 154.1G
[--] Other process memory: 0B
[--] Total buffers: 50.4G global + 52.7M per thread (2000 max threads)
[--] P_S Max memory usage: 867M
[--] Galera GCache Max memory usage: 0B
[OK] Maximum reached memory usage: 69.0G (73.22% of installed RAM)
[!!] Maximum possible memory usage: 154.1G (163.47% of installed RAM)
[!!] Overall possible memory usage with other process exceeded memory
[OK] Slow queries: 0% (0/15K)
[OK] Highest usage of available connections: 17% (346/2000)
[OK] Aborted connections: 0.50%  (2/401)
[OK] Query cache is disabled by default due to mutex contention on multiprocessor machines.
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 1K sorts)
[!!] Joins performed without indexes: 47
[!!] Temporary tables created on disk: 55% (519 on disk / 927 total)
[!!] Thread cache hit rate: 13% (346 created / 401 connections)
[OK] Table cache hit rate: 98% (589 open / 595 opened)
[OK] Open file limit used: 1% (81/8K)
[OK] Table locks acquired immediately: 100% (552 immediate / 552 locks)

-------- Performance schema ------------------------------------------------------------------------
[--] Memory used by P_S: 867.5M
[--] Sys schema isn't installed.

-------- ThreadPool Metrics ------------------------------------------------------------------------
[--] ThreadPool stat is enabled.
[--] Thread Pool Size: 24 thread(s).
[--] Using default value is good enough for your version (10.4.6-MariaDB)

-------- MyISAM Metrics ----------------------------------------------------------------------------
[!!] Key buffer used: 18.2% (24M used / 134M cache)
[OK] Key buffer size / total MyISAM indexes: 128.0M/23.0K

-------- InnoDB Metrics ----------------------------------------------------------------------------
[--] InnoDB is enabled.
[--] InnoDB Thread Concurrency: 0
[OK] InnoDB File per table is activated
[OK] InnoDB buffer pool / data size: 50.0G/1.9G
[OK] Ratio InnoDB log file size / InnoDB Buffer pool size: 6.0G * 2/50.0G should be equal to 25%
[OK] InnoDB buffer pool instances: 50
[--] Number of InnoDB Buffer Pool Chunk : 400 for 50 Buffer Pool Instance(s)
[OK] Innodb_buffer_pool_size aligned with Innodb_buffer_pool_chunk_size & Innodb_buffer_pool_instances
[OK] InnoDB Read buffer efficiency: 99.92% (31587444 hits/ 31612740 total)
[!!] InnoDB Write Log efficiency: 168.97% (49 hits/ 29 total)
[OK] InnoDB log waits: 0.00% (0 waits / 78 writes)

-------- AriaDB Metrics ----------------------------------------------------------------------------
[--] AriaDB is enabled.
[OK] Aria pagecache size / total Aria indexes: 128.0M/2.5M
[OK] Aria pagecache hit rate: 99.1% (59K cached / 542 reads)

-------- TokuDB Metrics ----------------------------------------------------------------------------
[--] TokuDB is disabled.

-------- XtraDB Metrics ----------------------------------------------------------------------------
[--] XtraDB is disabled.

-------- Galera Metrics ----------------------------------------------------------------------------
[--] Galera is disabled.

-------- Replication Metrics -----------------------------------------------------------------------
[--] Galera Synchronous replication: NO
[--] No replication slave(s) for this server.
[--] Binlog format: MIXED
[--] XA support enabled: ON
[--] Semi synchronous replication Master: OFF
[--] Semi synchronous replication Slave: OFF
[--] This is a standalone server

-------- Recommendations ---------------------------------------------------------------------------
General recommendations:
    MySQL was started within the last 24 hours - recommendations may be inaccurate
    Reduce your overall MySQL memory footprint for system stability
    Dedicate this server to your database for highest 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 which have no LIMIT clause
    Consider installing Sys schema from https://github.com/mysql/mysql-sys for MySQL
    Consider installing Sys schema from https://github.com/good-dba/mariadb-sys for MariaDB
Variables to adjust:
  *** MySQL's maximum memory usage is dangerously high ***
  *** Add RAM before increasing MySQL buffer variables ***
    join_buffer_size (> 50.0M, or always use indexes with JOINs)
    tmp_table_size (> 100M)
    max_heap_table_size (> 100M)
    thread_cache_size (> 2000)
EN

回答 1

Server Fault用户

发布于 2019-07-19 16:53:44

基准测试是一项棘手的工作。有些基准擅长比较两种不同的硬件/软件配置,但很少有基准能够很好地返回系统绝对能力的实际估计值。

这个例子似乎在极短的毫秒内用40个相同的、与CPU绑定的查询来关闭服务器。因为只有24个核,所以这些过程很快就开始相互绊倒。注意:timings女士: 575 1081 1376;这证实了这一绊脚石。

如果第一个查询允许在25开始之前运行575 is,那么处理可能会很好地“永远”进行。这大约是每秒40,而不是40“一次”。

因此,如果ab能够分散请求(每25 is新请求一次),您可能会看到“没有问题”。

同时,对于网页来说,575毫秒的回复时间太长了。让我们看看查询(查询)与加快它的眼睛。

在现实生活中,http请求来自web服务器,介于“同时”和“均匀间隔”之间。你的测试只提供了一个上限。

票数 2
EN
页面原文内容由Server Fault提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://serverfault.com/questions/975927

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档