Nov28

【原创】关于APCU序列化在PHP7中使用的注意事项

Author: leeon  Click: 74   Comments: 0 Category: php  Tag: php,apcu,php7

这两天线上服务器fpm频繁coredump,strace跟踪到php返回

write(2, "zend_mm_heap corrupted\n", 23) = 23

当时以为是php内核内存触发的bug,由于线上环境部署的是最新版本的php7+phalcon3,所以刚开始是怀疑新版本的程序的兼容性问题,但是在线下环境下模拟还原线上的所有基础环境时发现并不是如此,故一一比对线上的不同,发现运维在配置文件中使用了与线下不同的配置项,我们的程序同时用到了apcu的扩展,发现运维在配置的时候指定了apcu的序列化方法:
apc.serializer=igbinary
采用的是igbinary算法,但是我们线上新部署的环境中并没有支持到这个算法的扩展,故导致了问题发生。
解决方法为从pecl中下载igbinary扩展,安装并配置到ini文件中即可。
备注:
原先运维在使用php5.6的时候并没有直接编译igbinary,但是配置文件中依然指定了igbinary,但php5.6进程并不会在coredump,这里php7针对igbinary的支持应该做了改变。

Jun15

【原创】PHP取模时为负数小计

Author: leeon  Click: 565   Comments: 0 Category: php  Tag: php,取余数

      用了几年的php今天才注意到在32位环境下php去大数字取模为负数情况存在。在32位php运行环境下,被取模的数字不能大于数字2147483648,除了php手册中说明的采用fmod函数的方式获取正确数值外,现在大部分的服务器已经是64位话,在php编译为64位运行时时,是可以正常支持到更大的取模运算,这时候当数值大于2147483647时取模是不会出现负数的。也就是说当我们php运行在64位环境下同时编译的php为64位版本一般不会出现负数问题,除非你的被取模数字大于9223372036854775808,此时已经超过有符号64位的最大取值范围了。

    注意如果取模数值超过了64位的最大整型值,这时候取模得到的数值都为0。如果更大的数值取模保险的方式还是使用fmod函数,

Apr12

【原创】论外部接口调用的设计原则

Author: leeon  Click: 844   Comments: 0 Category: 架构  Tag: api

      今日后端系统发生一次严重的redis cpu 100%异常问题。期初是怀疑系统硬件问题,因为后端代码已经好几天没有发不过,理应是不会突然故障。于是一步步排查,首先从redis本身入手,其本身redis 占用率过高网上的说法也已经概括的比较全面了,不外乎bgsave,keys模糊查找和滥用排序导致redis性能下降。但是从我们本身的系统架构而言,redis的cpu使用率一直都稳定在3%左右,数据大小本身也不高,rdb文件本身也不大只有几百兆,占用的系统内存页也只有整个硬件内存的20%。磁盘io,cpu都很稳定, 

      首先通过strace定位的方法监控php-fpm和redis进程是否有异样,发现php-fpm都卡在和redis的通信上,而redis进程都卡在频繁读写上。info查看redis的total_commands_processed数值,尽然每秒高达20w次左右,我们知道通过redis的benchmark测试redis的性能通常每秒不走pipleline也差不多这个数值了,业务突然能将redis的吞吐能力消耗干净那肯定不外乎受外部大规模的压力攻击或系统内部的死循环导致。

   攻击肯定就谈不上了,nginx上访问日志很正常,通过redis的monitor命令查看redis的实时执行命令,发现全部都是对同一个key进行写入和查询。接着通过get这个key输出的值发现了端倪。继而定位到业务代码中的执行片断。

     问题排查到现在就好解决了,代码级定位发现了原先设计代码中不合理的设计,对于第三方外部接口调用没有采取异常情况的最终返回,导致不停的递归调用了第三方接口,但是第三方接口又因为查询条件的改变,导致始终执行不成功。这样无法缓存正常数据,就导致不停的查缓存和写缓存操作。

    通过这次问题排查和解决,总结了如何使用第三方接口服务的设计原则:

1. 不管如何设计接口切记尽量避免使用递归来请求接口,如果没有捕获到极端异常,有可能导致程序死循环。

2. 所有外部接口都要设计一个最终失败的逻辑。

3. 对第三方接口增加缓存逻辑的同时,一定要对失败的结果也做一份缓存,避免频繁请求第三方接口而导致同步io延时的问题。

4. 千万不要认为大厂的API接口都是极其稳定的,是的!今天遇到的就是百度的云API提供的接口,虽然大厂通常对自己提供的服务接口都有做API自动化测试,但是故障恢复能力并不一定每个业务团队都能及时响应。更不要以为大厂的开发们都是各个经验丰富,知道如何保证API的可用性和稳定性。如果哪天他们升级了代码将接口的传参做了调整,这种对调用方的伤害也是巨大的。一个设计合理的接口一定遵循一点,同版本接口输入和输出必须保证确定性,做了调整的接口一定得区分版本号。

Mar31

【原创】关于elasticsearch中拼音搜索的性能问题

Author: leeon  Click: 1152   Comments: 0 Category: 架构  Tag: elasticsearch,拼音

近日在elasticsearch按照网上的教程添加拼音支持后发行搜索性能衰减非常大,以前几百万的数据搜索关键字也只需要三四是毫秒,加入了多字段的拼音支持后搜索指定字段性能衰减了6-8倍。类似于网上的配置如下:

在索引分词器中配置如下:

[code="plain"]
index.refresh_interval: 1s
index:
analysis:
tokenizer:
my_pinyin:
type: "pinyin"
first_letter: "none"
padding_char: ""
analyzer:
ik_syno:
type: custom
tokenizer: ik_max_word
filter: [my_synonym_filter]
ik_syno_smart:
type: custom
tokenizer: ik_smart
filter: [my_synonym_filter]
pinyin_analyzer:
tokenizer: my_pinyin
filter: ["word_delimiter","my_ngram"]
py_analyzer:
tokenizer: my_pinyin
filter: ["standard"]
filter:
my_synonym_filter:
type: synonym
synonyms_path: analysis/synonym.txt
ignore_case: true
my_ngram:
type: "nGram"
min_gram: 2
max_gram: 5

[/code]

[code="plain"] {
"folks": {
"properties": {
"name": {
"type": "multi_field",
"fields": {
"name": {
"type": "string",
"store": "no",
"term_vector": "with_positions_offsets",
"analyzer": "pinyin_analyzer",
"boost": 10
},
"primitive": {
"type": "string",
"store": "yes",
"analyzer": "keyword"
}
}
}
}
}
}
[/code]

这种模式配置的字段映射会极大的降低搜索性能,如果想用拼音搜索关键字建议单独设立一个独立的字段来做,不要用multi_field复合字段的方式来配置,这样会大大降低在指定字段中搜索的性能,我猜测如果使用nGram方式来生成分词,会导致生成的token非常多,导致搜索匹配的数据太多导致查询太慢。

分类

标签

归档

最新评论

我也不知道叫个啥好在00:59:46评论了
shell中使用while循环ssh的注意事项
司马成空在16:14:13评论了
【原创】ZendStudio中格式化HTML代码错位问题修正
Owen在22:56:46评论了
【原创】MyBatis Generator使用小记
waltye在23:38:05评论了
【原创】武汉互联网公司介绍[2016年8月更新版]
小甲虫在18:05:31评论了
shell中使用while循环ssh的注意事项

我看过的书

链接

其他

访问本站种子 本站平均热度:5687 c° 本站链接数:27 个 本站标签数:402 个 本站被评论次数:86 次