最近在梳理某项目上各服务接口的性能情况,遇到两个问题。以下是定位和解决问题的一个思路,分享给大家。 业务之前并没有详细的性能日志记录,仅在电信机房(T机房)进行了性能测试,结果是各接口满足预期,服务上线。 在进一步对接口进行性能分析时,对各业务接口的关键路径添加了日志统计,通过日志进行分析,将接口的延迟进行统计,接入Grafana,观察数据后,发现两类问题。 连接MongoDB的服务,网通机房(C机房)延迟比电信机房(T机房)要高。 连接Mysql的服务,网通机房(C机房)延迟比电信机房(T机房)高。 NOTE: 这些服务接口,都是只读,没有写操作。 对两类问题分别进行排查: MongoDB 简单的排查后发现,MongoDB实例有过一次迁移,并且迁移后只保留了电信机房(T机房)的实例,网通机房(C机房)没有从库,所以网通机房(C机房)延迟比电信机房(T机房)高。对网通机房(C机房)部署了从库实例后,却意外发现电信机房(T机房)的延迟比网通机房(C机房)高了。再次排查后发现,代码中配置的MongoDB的读策略是secondary(从库优先),所以网通机房(C机房)有从库后,电信机房(T机房)也去网通机房(C机房)读取,导致了电信机房(T机房)的延迟变高。更改读策略为nearest(就近优先),有所好转,但并没有预想的效果那么好。仔细看下官方文档 The driver reads from a random member of the set that has a ping time that is less than 15ms slower than the member with the lowest ping time. Reads in the MongoClient::RP_NEAREST mode do not consider the member’s type and may read from both primaries and secondaries. 就会发现,nearest是在客户端维护一个到各个实例延迟小于15ms的集合,而我们电信机房(T机房)到网通机房(C机房)是光纤直连,延迟在12ms左右,所以,每次客户端可能会连接到电信机房(T机房),也可能到网通机房(C机房)。 这点在以后的应用中,大家可以注意下。 Mysql 在所有的服务中,只有一个服务接口是读mysql实现的,而这个接口的表现更是奇怪,网通机房(C机房)的延迟比电信机房(T机房)多100 ms+。
阅读全文

/var/tools/php-5.6.17/ext/iconv/iconv.c:2512: undefined reference to libiconv_open’ ext/xmlrpc/libxmlrpc/encodings.o: In functionconvert’: /var/tools/php-5.6.17/ext/xmlrpc/libxmlrpc/encodings.c:73: undefined reference to libiconv_open’ /var/tools/php-5.6.17/ext/xmlrpc/libxmlrpc/encodings.c:81: undefined reference tolibiconv’ /var/tools/php-5.6.17/ext/xmlrpc/libxmlrpc/encodings.c:101: undefined reference to `libiconv_close’ collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 在阿里云安装php时,make的时候,发生了libiconv错误,通过安装libiconv,指定with-iconv-dir也没解决。最终是在make时加了一个参数,然后顺利编译通过的。 make ZEND_EXTRA_LIBS=‘-liconv’
阅读全文

大家应该都知道,开启php的coredump输出,修改ulimit -c就可以了,但是很多情况下,会提示权利受限,无法修改

[fukun@10.16.29.xxx]$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 30678
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 32768
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1024
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

$ ulimit -c unlimited
-bash: ulimit: core file size: cannot modify limit: Operation not permitted

解决方案:

1.检查配置

看看shell配置里有没有 ulimit -c 0 这种类似的关闭的操作,例如 $HOME/.bash_profile 或者 $HOME/.bashrc 之类的,如果有,注释掉。

#
# Do not produce core dumps
#
# ulimit -c 0


阅读全文

还是360指数项目,需要用到Query归一化,但是公司内只有c++版本的,数据分析的同事用的都是那个二进制可执行文件来处理,但是我们前端又不可能跑system()方法吧,太不安全了,所以要来了源代码,打算封装成一个php扩展。

下边就讲一下我的封装过程。

首先,要到了Query归一化的C++版本源代码。

query归一化

query归一化

引用第三方的类库有两种方法,一种是静态引用,一种是动态引用,推荐使用静态引用,因为静态引用的情况下,会把类库打包到php的扩展.SO文件中,这样我们不必担心依赖关系,带着类库到处跑了。


阅读全文

今天有运营同事反馈在使用一个内部的运营工具时,有些操作失败,后来抓包发现,post到服务端的数据是正常的,在服务端接受到的数据却并不完整,有缺失。很是奇怪。看了下nginx的error log,发现问题所在了,原来是php有设置最大接受变量个数。 2014/04/02 18:06:33 [error] 23623#0: *1115 FastCGI sent in stderr: “PHP message: PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0” while reading response header from upstream, client: 10.18.120.25, 所以,需要做的就是修改下php.ini中的设置:max_input_vars ,默认没有开启,默认值是1000,修改为自己合适的值,就可以了。
阅读全文

undefined symbol: itoa

itoa不是c的一个标准输入输出,所以可能不在stdlib.h里。 解决办法很简单,不就是要把整型转为字符串么。sprintf 格式化输出一下就好了。 举个例子: int val = 177; char *val_s ; spprintf(&val_s, 0, “%d”, val);
阅读全文

php配置扩展时遇到了个这个问题:PHP Warning: PHP Startup: Unable to load dynamic library ‘/home/s/apps/php-5.2.6/extensions/curl.so’ – libcurl.so.3: cannot open shared object file: No such file or directory in Unknown on line 0 google了下,都说解决办法是: ln -s /usr/lib/libcurl.so.4 /usr/lib/libcurl.so.3 我看了下自己的lib目录,发现也没有 libcurl.so.4,然后又查没有libcurl.so.4怎么样,答案是: ln -s /usr/lib/libcurl.so.3 /usr/lib/libcurl.so.4 啊哈哈哈哈哈哈,乐死我了。 我个人觉得是curl.so不靠谱,从别的地方搞了一个拷贝过来,ok了。
阅读全文

作者的图片

DigDeeply

Technology Stack: PHP/Openresty/GoLang, and so on…

Web Develop Eneigneer

Beijing China