服务器资源限制有时很紧;为了防止内存耗尽,我不得不限制服务器进程。我需要一些专家的帮助,以了解我是否在正确的轨道上,并可能发现任何明显的设置变化,将有助于系统运行更多和更稳定。
最近,我的公司从共享主机升级到VPS。基本上,我们已经超越了我们的共享主机,并开始出现问题,因为主机挂起我们的网站,因为过度的CPU使用在周末。我们的网站用户倾向于每周星期五和星期六双倍或三倍,这在我们的情况下并不意外。(一周内每天大约有5000次访问~2500名游客,周末大约有9500次访问~4500名访客。)
现在我们在VPS上,我们没有CPU问题。(事实上,CentOS WHM控制面板显示我们处于".000201% CPU负载“状态。)然而,我们有内存不足的问题,导致崩溃.
我们的网站是基于WordPress的。但是,除了注释之外,很少有“写”活动;大多数用户只是看到我们创建的静态页面。
几个月前,也就是2012年10月,当我们第一次升级到VPS时,该网站在一周内运行良好,但每个周末都会被记忆所窒息。它经常会反复地坠毁(在24小时内,偶尔发生5-20次),通常从周五晚上开始,一直持续到周六下午。
在一周内,服务器持续运行在65-90%的内存使用率,而在周末它将达到100%,造成崩溃。
而采取的步骤
因为我是VPS的新手,所以我开始使用所有的默认设置。后来我开始调整,按照我在这个网站和其他网站上读到的关于解决内存问题的建议。
我已经对MySQL、PHP进行了调整,在下面的“当前配置”中总结了这一点。我还重新编译了Apache和PHP以删除不需要的模块。我为WordPress (W3T)安装了一个更好的缓存插件,并添加了APC操作码缓存。我还开始使用gz压缩,并将许多静态文件移到单独的子域。
我编写了一个漂亮的小脚本,用于按计划检查服务器状态,并根据需要重新启动它,它还向我发送服务器错误日志的记录,以帮助排除故障。(我知道,这只是一个创可贴,如果那样的话.)但是保持网站在线是很重要的,因为没有人愿意在周末坐在那里监视它。)
就在最近,大约一周前(2013年1月),我将服务器RAM从1GB(2GB可存储)升级到2GB(3GB可存储)。这似乎解决了大部分问题,但我偶尔会收到一个通知(大约每周一次),服务器挂起了,还有“无法应用进程槽”PHP错误。
它是一个Apache服务器,运行CentOS 6、Apache2 (Worker MPM)、PHP5.3.20 (FastCGI/fcgi)和MySQL 5.5.28。2GB内存(3GB可存储),24个CPU。
MySQL目前使用的内存约为618 MB,约占内存的20.1%。PHP每个进程最多消耗89 MB。Apache每个进程最多消耗14 MB。
典型的工作日top产出:
top - 15:31:13 up 89 days, 5:26, 1 user, load average: 1.54, 1.00, 0.70
Tasks: 49 total, 1 running, 48 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.2%us, 0.1%sy, 0.0%ni, 99.7%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 3145728k total, 1046444k used, 2099284k free, 0k buffers
Swap: 0k total, 0k used, 0k free, 0k cached不幸的是,我没有一个周末/最忙时间最高输出的例子。
Apache配置:
StartServers: 5
MinSpareThreads: 5
MaxSpareServers: 10
ServerLimit: 80
MaxClients: 56
MaxRequestsPerChild: 5000
KeepAlive: OffPHP配置:
MaxRequestsPerProcess 500
FcgidMaxProcesses 15
FcgidMinProcessesPerClass 0
FcgidMaxProcessesPerClass 8
FcgidIdleTimeout 30
FcgidIdleScanInterval 15
FcgidProcessLifeTime 60
FcgidIOTimeout 300
FcgidMaxRequestLen 268435456MySQL配置:
[mysqld]
max_user_connections = 75
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
skip-external-locking
sort_buffer_size = 512K
# MyISAM #
key_buffer_size = 32M
myisam_sort_buffer_size = 16M
#myisam_recover = FORCE,BACKUP
# SAFETY #
max_allowed_packet = 8M
#max_connect_errors = 1000000
# CACHES AND LIMITS #
tmp_table_size = 104M
max_heap_table_size = 104M
join_buffer_size = 208K
#query_cache_type = 0
query_cache_size = 32M
max_connections = 150
thread_cache_size = 4
#open_files_limit = 65535
table_cache = 512
#table_definition_cache = 1024
table_open_cache = 2048
wait_timeout = 300
# INNODB #
#innodb_flush_method = O_DIRECT
#innodb_log_files_in_group = 2
#innodb_log_file_size = 64M
#innodb_flush_log_at_trx_commit = 1
#innodb_file_per_table = 1
innodb_buffer_pool_size = 416M
# This setting ensures that aio limits are not exceeded
# (default is 65536, each instance of mysql takes 2661 with this enabled)
innodb_use_native_aio = 0
# LOGGING #
log-slow-queries
log-queries-not-using-indexes如有任何帮助/建议,将不胜感激。网站地址是3abn.org。
发布于 2013-01-15 22:09:49
你已经在用FastCGI运行PHP了,所以我不知道你还能做些什么来精简它。你好像在十字路口..。
有几种选择:
编辑:你是说你已经安装了很多缓存工具。Cache =吃掉更多的RAM,这样下一个请求(S)就会运行得更快。如果你的RAM很低-缓存可能不是世界上最好的东西。
发布于 2013-01-15 22:31:05
我的第一条建议是:离开VPS。
我已经听够了关于VPS系统上与内存(和OOM-Killer)相关的问题的抱怨,我认为典型的VPS托管提供商并没有提供生产级解决方案--它不是“虚拟专用服务器”,而是“在现有操作系统之上的半虚拟化,其资源限制设计很差,因此与真正的机器不同”。
(你似乎被最常见的区别咬了:一个"VPS“没有交换空间,所以当你比你的提供者分配的内存多一个字节时,事情就分崩离析了。)
如果您不能或不愿意在您自己的硬件上托管高质量的数据中心,您应该考虑一个云服务,它看起来像一个“正常”的服务器,带有交换等(Amazon就是这样的选项之一)。这些解决方案的定价介于"VPS“解决方案和专用硬件之间,但提供了更接近”真正硬件“的操作体验,并让您避免了现在的情况。
请注意,无论如何,您仍然需要适当地调整系统的大小--您的VPS/Cloud解决方案/专用硬件应该有足够的RAM来处理峰值负载而不进行交换。
(质量) Cloud或专用硬件解决方案的优点是,当您到达交换点(例如,禁用OOM-杀手并让malloc()失败)时,您可以更好地控制发生的事情。
发布于 2013-01-15 23:35:24
从你发布的信息来看:
。您的VPS似乎运行在OpenVZ或并行Virtuozzo下。如果主机提供商过度分配(很多事情),您的服务器将永远无法使用第三个内存。
最糟糕的是,您的VPS可能会被允许爆裂一小段时间,但之后OOM杀手将开始杀死过程。OOM杀手可以被调整(从主机提供商端),以防止更重要的进程被杀死(例如ssh、bind、apache、mysql -使用优先级),但是由于同一节点上的其他客户端可能运行相同的典型设置,这是没有帮助的。
3G隔离,突发失效。
。如果网页确实是静态的和小的,您可以使用缓存反向代理。是的,缓存使用内存。但是缓存也阻止了PHP进程的产生,而PHP进程往往要求很高。
(你需要做一些数学和/或尝试.这不是一个绝对的解决办法)
。禁用APC,或运行PHP。
对于Fcgi,每个PHP进程都有自己的APC操作码缓存。对所有PHP进程使用FPM共享公共缓存。或者让装甲运兵车瘫痪。无论如何,您似乎并不需要它(操作码缓存在降低CPU使用率方面比内存使用效率高得多;)
https://serverfault.com/questions/469440
复制相似问题