自上周以来,我拥有一个运行在VPS上的网站。 从星期一到星期六,一切都很顺利。 该网站每天有大约4.500个独立访问者,平均负载和响应时间都很好。
在星期天,该网站有大约11.000独立访客,因为我们提供独特和独特的内容在当天。 内容存储在一个MySQL数据库中,该数据库运行在不同的VPS服务器上并使用InnoDB引擎。 这是事情出错的地方。 由于访问量的增加,负载平均值会上升到极点,直到网站无法访问。
这是最高的输出:
This is an automated message notifying you that the 5 minute load average on your system is 238.37. This has exceeded the 10 threshold. One Minute - 237.31 Five Minutes - 238.37 Fifteen Minutes - 231.1 top - 16:41:12 up 5 days, 18:51, 1 user, load average: 238.68, 238.62, 231.25 Tasks: 517 total, 246 running, 271 sleeping, 0 stopped, 0 zombie Cpu(s): 1.8%us, 0.3%sy, 0.0%ni, 97.6%id, 0.0%wa, 0.0%hi, 0.1%si, 0.2%st Mem: 3922920k total, 3542968k used, 379952k free, 2736k buffers Swap: 1048564k total, 105316k used, 943248k free, 142772k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 14395 apache 20 0 313m 13m 4044 R 2.8 0.4 0:09.81 /usr/sbin/httpd -k start -DSSL 13405 apache 20 0 314m 15m 4432 R 2.3 0.4 0:17.87 /usr/sbin/httpd -k start -DSSL 15865 apache 20 0 312m 13m 4176 R 2.3 0.4 0:01.28 /usr/sbin/httpd -k start -DSSL 15930 apache 20 0 310m 11m 4060 R 2.3 0.3 0:00.88 /usr/sbin/httpd -k start -DSSL 15978 apache 20 0 310m 11m 4048 R 2.3 0.3 0:01.08 /usr/sbin/httpd -k start -DSSL 16041 apache 20 0 309m 10m 4052 R 2.1 0.3 0:00.58 /usr/sbin/httpd -k start -DSSL 16082 apache 20 0 211m 4192 2276 R 1.9 0.1 0:00.09 /usr/sbin/httpd -k start -DSSL 14298 apache 20 0 310m 11m 4044 R 0.6 0.3 0:09.56 /usr/sbin/httpd -k start -DSSL 14457 apache 20 0 311m 11m 4068 R 0.6 0.3 0:10.18 /usr/sbin/httpd -k start -DSSL 14486 apache 20 0 310m 11m 4464 R 0.6 0.3 0:06.13 /usr/sbin/httpd -k start -DSSL 15287 apache 20 0 313m 14m 4048 R 0.6 0.4 0:05.21 /usr/sbin/httpd -k start -DSSL 15363 apache 20 0 310m 11m 4064 R 0.6 0.3 0:04.13 /usr/sbin/httpd -k start -DSSL 15400 apache 20 0 313m 13m 4048 R 0.6 0.4 0:04.09 /usr/sbin/httpd -k start -DSSL 15404 apache 20 0 310m 11m 4056 R 0.6 0.3 0:04.22 /usr/sbin/httpd -k start -DSSL 15649 apache 20 0 313m 14m 4432 R 0.6 0.4 0:02.88 /usr/sbin/httpd -k start -DSSL 15675 apache 20 0 310m 10m 4044 S 0.6 0.3 0:02.22 /usr/sbin/httpd -k start -DSSL 15692 apache 20 0 310m 11m 4084 R 0.6 0.3 0:01.46 /usr/sbin/httpd -k start -DSSL 15702 apache 20 0 311m 12m 4044 R 0.6 0.3 0:01.85 /usr/sbin/httpd -k start -DSSL 15719 apache 20 0 310m 10m 4048 R 0.6 0.3 0:02.32 /usr/sbin/httpd -k start -DSSL 15781 apache 20 0 318m 18m 4044 R 0.6 0.5 0:01.91 /usr/sbin/httpd -k start -DSSL 15788 apache 20 0 312m 13m 4048 R 0.6 0.4 0:02.13 /usr/sbin/httpd -k start -DSSL 15823 apache 20 0 310m 11m 4060 R 0.6 0.3 0:02.04 /usr/sbin/httpd -k start -DSSL 15837 apache 20 0 311m 12m 4052 R 0.6 0.3 0:01.64 /usr/sbin/httpd -k start -DSSL
在星期天,网站必须执行一个非常大的查询,并在不同的表上添加一些左连接。
该网站在VPS上运行,包含2个2.4 Ghz处理器和4GB内存。 该数据库运行在一个SSD VPS上,包含2个2.4 Ghz处理器和2GB RAM。
在具体的星期天,我也在服务器的ErrorLog中得到这个消息:
Sun Nov 24 15:03:34 2013] [error] server reached MaxClients setting, consider raising the MaxClients setting
该网站是使用PHP Codeigniter框架创build的,并且在共享主机的前8周(使用相同的代码)上工作良好。 那几周之后,问题就开始了,这就是我决定搬到VPS服务器的原因。 但问题似乎还在继续。
我完全不知道事情出错了,所以任何帮助,他会高度赞赏。
你的问题的答案是尽可能的使用内存caching。 即memcache,varnish等…….然后使用nginx,它可以水平缩放,在它后面,一个适合你的负载的php-fpm池,完全与upream nginx盒子相连。
一旦达到一定程度的stream量,就不会像硬件caching那样把硬件投入到硬件上,而是可以单独升级/更新单独的分层。
你不能有一个单一的VPS超高可用性的网站,除非它的静态HTML,甚至然后清漆是理想的。
得到一对haproxy前端负载平衡器,分发到清漆,从nginx / php / memcache / redis / mysql(postgres)拉… …..它简而言之:P
MaxClients是一个Apache服务器指令。 有几个相关的指令,但它们都以不同的方式关注对Apaches处理请求的限制。
这样做的动机是不要让阿帕奇消耗这么多的资源,以至于威胁整个系统的稳定。 因此,如果增加MaxClients和其他类似的指令,就需要在系统资源(如RAM)上保留一个眼睛。
在这里阅读更多: MaxClients指令
但是,首先,即使您发现了一些症状(显然,或者您不会发布),究竟问题的具体位置还不清楚。 Apache可能会向您显示其他地方存在的问题。
但是在输出结果中,你关注的是Apache,因为那部分是相当直接的,所以我们从这里开始吧。
在链接中,MaxClients定义了httpd服务的最大请求数。 当填满时,请求在ListenBackLog中排队。 如果满了,客户被拒绝。
无论是maxclients填满,因为同时请求的数量是如此之多。 那么你需要规定那个比较容易的事情。 在Apache层放大和/或缩小,直到安全的一面,或直到数据库层最大化。
或者maxclients填满了,因为它们由于底层而不能足够快地服务。 因此,请求堆积在Apache中,直到不再被接受。 这不是同样容易解决,因为它首先提出了许多问题。 即使您还没有完全清楚(即时),您也可以立即将注意力集中在数据库层上。
看看客户端是否被拒绝了,等等。如果你把页面状态代码取到你的日志中,你可以parsing… 503我似乎记得,但你应该谷歌检查我。 这只是为了了解您的交付,并设置一个基准来比较下一次发生的情况。
这里有一些想到的问题。 我意识到find答案。 说起来容易做起来难,除非你有能给你最高见识的工具。 我们使用Dynatrace(面向Java的),这是非常昂贵的,但可以在几分钟内回答这些问题,甚至在代码中的组件级别,即使是一个系统pipe理员。 这使得在代码,基础设施或组合中定位因果关系更为迅速。 我知道市场上还有其他工具,可能还有开源的替代品。 我只是没有经验与这些工作。 我想也可以将debugging和应用程序日志编码为相同的东西,这只是一个耗费大量工作时间的问题。
这些请求是否需要更长的时间来服务于您所描述的错误? 我的Apachelogs显示了多长时间来处理每个请求。 我不记得是否是默认的,但如果你没有,可以在本周初发布这样的指令。
如果他们需要更长的时间,是由于不同的请求模式或简单的更大的数字?
在Apache服务器负载方面,你服务了很多静态内容还是主要是dynamic的? 你有基准静态还是只是dynamic? 这个问题是相关的,因为静态内容可以分离到不同的交付服务器,但也RAMcaching(清漆在另一个答案中提到)。 在一些交付中,节省可能是显着的,而在另一些情况下则不是。
是否有(实质上)相同的dynamic内容的请求,或每个请求重新计算? 换句话说,是否有可能注入一个早期的caching层来捕获某些dynamic内容?
更深入地看,它处理中的代码量大吗? 一个基线可以使用主要触发逻辑但相对较less的数据库调用的请求吗? 也许这是需要优化或扩大/缩小的代码?
数据库调用是优化的还是浪费的,无论是数量还是查询的制定方式? 在重载时,每次通话的响应时间是多less? 响应时间增加了吗? 通话数量是否达到了大量?
你会发现它越来越靠近数据库,每一层都在寻找优化,caching,分发(扩展),原始function(扩大)的机会。
也许你已经有了所有这些答案,完全正确地把innodb归零,我不能告诉给出的信息! 我所能提供的是有条不紊的问题,可能是相关或不可能的,可能会响铃或不响.-)
但是,赶快把Apache赶出这个等式似乎是一个好主意(因为它可能正在遭受附带损害)。 如果确实可以validationApache不是根本原因,那么重点关注应用程序以及它如何使用数据库。
基本统计数据,例如networkingIO,RAM消耗,CPU消耗,磁盘IO,页面错误等,对于所涉及的机器也是有帮助的。