最新 | 最热门 | 最高评价

+0  谈谈PHP的Reload操作

Tag: Technical | PHP
老王 发于 2016年12月11日 19:00 | 点击: 656 | 展开摘要
通常修改了 PHP 的配置后,为了让修改生效会执行 reload,而不是 restart,因为有很多前辈告诫过我们,reload 能保证整个过程的平滑性,所谓平滑性指的是在 reload 的过程中,旧的进程在处理完当前请求前不会提前终止。很多年来,我一直坚信这个结论,直到有一天,当我 reload 的时候,出现了 502 错误,让我不得不重新思考。

如何重现问题呢?让我们写一个简单的脚本来模拟:

<?php

sleep(11);
echo "foo";

?>

查看全文: http://www.udpwork.com/item/15998.html

+0  实战ElasticStack

Tag: Technical | Elastic
老王 发于 2016年12月11日 15:22 | 点击: 902 | 展开摘要
我对 ElasticStack 可以说是既熟悉又陌生,说熟悉是因为很久以前就已经开始使用 ELK 来分析日志了,说陌生是因为以前的 ELK 环境都是同事搭建的,我主要是看看 Kibana 面板而已。随着 V5 的发布,ELK 全面进化为 ElasticStack,该自己动手了。

实际操作前最好大致浏览一下官方文档,以便对 ElasticStack 各个组件的作用有一个基本概念,如果看完文档还没搞清楚,那么至少要看明白下面这张图:

ElasticStack

整个流程相当简

查看全文: http://www.udpwork.com/item/15997.html

+0  手把手教你用Sar诊断问题

Tag: Technical | Linux
老王 发于 2016年12月02日 15:18 | 点击: 989 | 展开摘要
如今各种高大上的监控工具早已经让人目不暇接了,但是熟悉基础的 Linux 监控命令依然是必要的,就好比 IDE 再好用,我们也得学会 vi 或者 emacs 才行。如果让我选一个必须学会的 Linux 监控命令的话,那么我想我一定会选 sar,没有之一。

监控命令 sar 隶属于 sysstat 包,监控的内容可以说是无所不包,常见的有:

sar -q:查看 Load

sar -u:查看 CPU

sar -r:查看 Memory

sar -b:查看 IO

除了这些

查看全文: http://www.udpwork.com/item/15956.html

+0  史上最LOW的在线DDL解决方案

Tag: Technical | MySQL | PostgreSQL
老王 发于 2016年11月23日 18:31 | 点击: 328 | 展开摘要
说起在线 DDL,最常见的操作莫过于在线加一个字段或者索引,不过如果数据量比较大的话,伴随而来的往往是长时间的等待,更要命的是系统在操作期间很可能会出现不可用的情况,所以一般只能等到凌晨操作,简直就是梦魇一般的存在。

在 PostgreSQL 中,如果注意使用方法,那么在线 DDL 并不是一个太难的事情。这里面说注意使用方法,指的是 PostgreSQL 跟其它一些数据库一样,在加字段或者索引的时候会锁住表,不过有一些技巧可以绕开此限制:

加字段:使用 ALTER TAB

查看全文: http://www.udpwork.com/item/15957.html

+0  一个PHP实现的ID生成器

Tag: Technical | PHP
老王 发于 2016年11月03日 20:03 | 点击: 249 | 展开摘要
通常来说,不管使用什么数据库,表里都有一个名为 id 的主键,既然是主键,那么必然要满足唯一性,对于 MySQL 用户来说,它多半是一个 auto_increment 自增字段,也有一些别的用户喜欢使用 UUID 做主键,不过对 MySQL(特别是 InnoDB)来说,UUID 通常不是一个好选择,因为聚簇索引要求物理数据按照主键排序,而 UUID 本身是无序的,所以会带来很多不必要的 IO 消耗。于是乎我们得到一个结论:ID 最好是顺序的唯一值。

如此说来,就用 MySQ

查看全文: http://www.udpwork.com/item/15958.html

+0  实战Pinba

Tag: Technical | PHP
老王 发于 2016年10月26日 16:33 | 点击: 219 | 展开摘要
谁都知道监控系统很重要,但是要自己搭建一套好用的系统却不是一件简单的事情。国内已经有不少厂商提供类似的服务,比如:OneAPM、听云,其原理就是通过在服务器上部署一套探针,把数据汇总上报,但是问题却不像说起来这么简单,我曾经买过国内某个厂商高大上的 APM 服务,谁知道它监控的指标太多了,并且无法自定义,结果导致一上线,系统性能就下降百分之二十,最后无奈只好放弃。

我想要的是一种对系统性能影响尽可能小的监控系统,它不需要监控太多指标,只要有 RPS、CPU、内存、响应时间等

查看全文: http://www.udpwork.com/item/15959.html

+0  关于FIN_WAIT2

Tag: Technical | Linux | TCP
老王 发于 2016年09月05日 22:30 | 点击: 652 | 展开摘要
前些天,有朋友问我关于 FIN_WAIT2 的问题:如果主动关闭的一方在进入 FIN_WAIT2 状态后没有收到被动关闭的一方发送的 FIN 包,那么会怎样?

让我们热热身,通过一张旧图来回忆一下 TCP 关闭连接时的情况:

TCP Close

按照正常的状态迁移路径,当 FIN_WAIT2 收到 FIN 包后会迁移到 TIME_WAIT 状态。如果没有收到 FIN 包,那么连接状态会如何迁移,我们不妨测试一下:

#!/usr/bin/env python

impo

查看全文: http://www.udpwork.com/item/15960.html

+0  如何判断GCC的版本

Tag: Technical | Linux
老王 发于 2016年09月01日 14:53 | 点击: 699 | 展开摘要
我说的 GCC 版本可不是指的「gcc –version」,而是指的上到 Linux 内核,下到 PHP 之类的软件,是用哪个版本的 GCC 编译的。

先看看如何判断 Linux 内核是用什么版本的 GCC 编译的?

shell> cat /proc/version
... (gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC) ) ...

shell> /lib64/libc.so.6
GNU C

查看全文: http://www.udpwork.com/item/15961.html

+0  白话火焰图

Tag: Technical | Linux | Performance
老王 发于 2016年08月18日 13:44 | 点击: 193 | 展开摘要
很多人感冒发烧的时候,往往会模仿神农氏尝百草的路子:先尝尝抗病毒的药,再试试抗细菌的药,甭管家里有什么药挨个试,什么中药西药,瞎猫总会碰上死耗子,如此做法自然是不可取的,正确的做法应该是去医院验个血,确诊后再对症下药。

让我们回想一下我们一般是如何调试程序的:通常是在没有数据的情况下依靠主观臆断来瞎蒙,而不是考虑问题到底是什么引起的!毫无疑问,调优程序性能问题的时候,同样需要对症下药。好消息是 Brendan D. Gregg 发明了火焰图,可以一针见血的指出程序的性能瓶颈

查看全文: http://www.udpwork.com/item/15962.html

+0  记录一个多核CPU负载不均衡问题

Tag: Technical | Linux | PHP
老王 发于 2016年07月19日 21:07 | 点击: 208 | 展开摘要
昨晚和一位读者朋友讨论了一个问题:在一台多核 CPU 的 Web 服务器上,存在负载不均衡问题,其中 CPU0 的负载明显高于其它 CPUx,进一步调查表明 PHP-FPM 的嫌疑很大。话说以前我曾经记录过软中断导致过类似的问题,但是本例中可以排除嫌疑。

让我们在一台四核服务器上采样分析一下数据确认看看是否存在负载不均衡问题:

shell> mpstat -P ALL 1 10

CPU %usr %nice %sys %iowait %irq

查看全文: http://www.udpwork.com/item/15963.html

+0  EAV or JSON

Tag: Technical | MySQL
老王 发于 2016年06月29日 20:18 | 点击: 185 | 展开摘要
MongoDB 之类的 NoSQL 之所以流行,很大程度上取决于相对自由的 schema 设计,不管数据量多大,可以随时在线上环境添加新字段来保存新数据,而这种能力恰恰是传统的关系数据库所欠缺的,不过别担心,传统关系数据库有自己的应对之道。我们今天就讨论一下其中最具代表性的两种方法,看看孰优孰劣。

在讨论前,我们不妨虚拟一个业务场景:假设我们要做一个类似汽车之家的产品库,首当其冲的是如何保存汽车的各种属性,比如说:长度、宽度、高度、GPS 导航系统、倒车影像、上坡辅助、陡坡

查看全文: http://www.udpwork.com/item/15964.html

+0  如何正确发布PHP代码

Tag: Technical | PHP
老王 发于 2016年05月27日 20:47 | 点击: 200 | 展开摘要
几乎每一个 PHP 程序员都发布过代码,可能是通过 ftp 或者 rsync 同步的,也可能是通过 svn 或者 git 更新的。一个活跃的项目可能每天都要发布若干次代码,但是现实却是很少有人注意其中的细节,实际上这里面有好多坑,很可能你就在坑中却浑然不知。

一个正确实现的发布系统至少应该支持原子发布。如果说每一个版本都表示一个独立的状态的话,那么在发布期间,任何一次请求只能在单一状态下被执行。如此称之为支持原子发布;反之如果在发布期间,一次请求跨越不同的状态,那么就不能称

查看全文: http://www.udpwork.com/item/15965.html
|<<<1234567>>>| 一共12页, 135条记录