后端开发

背景 近来es查询很慢，kibana的discover界面偶尔还会因为查询请求超时而无法显示数据。/_cat/indices?v 等对es的查询也慢的出奇，需要1、2分钟才返回结果。 排查 top命令看了es的java进程，发现cpu一直很高，130%左右，一直没有下降过。查看es的日志，发现gc.log中几乎每秒都要触发一次GC Full GC (Allocation Failure)。内存不够用，又没有内存可回收，所以GC也不断。怪不得CPU这么高，大部分时间都用在gc上面了。 处理 调整es可使用的内存大小。编辑config/jvm.options，调整了Xms和Xmx的大小，由原来默认的1g调整为10g。（官方建议这个值不要超过物理内存的50%，也不要超过32G。详见官网说明）接着重启es就好了。观察cpu，虽然偶尔也会彪上130%，但总体来说正常了，查询也变得很快。 ps：es重启后，需要观察logstash是否退出了。如果退出，需要重新把logstash拉起来。 pss：这次是小坑，后面可能还有很多大坑需要踩。后续有cpu高、查询慢的问题也一并归类到该文。

为什么使用它 受够了mysql原生client后，你会爱上mycli的自动补全和高亮。对于我这种常常记不住表结构的人来说，自动补全真是爽得不行。 ps：sql新手谨慎使用，建议多裸写sql后再来使用该软件 安装 Mac brew install mycli CentOS # 请尽量先将pip升级到最新版本 pip install --upgrade pip yum install python-devel yum install libffi-devel easy_install mycli 使用方法 和mysql原生命令行一样： mycli -uname

Mysql的基本数据类型中并没有布尔型，之所以建表和数据操作中能够使用BOOLEAN是因为mysql将其作为了tinyint(1)的别名。用0表示false，1表示true。 但开发过程中，既然我们给某一字段定义为布尔型，那么在我们获取数据后，期望得到的必然是布尔值而不是0或1。因此我们可以在得到返回值后转换一下。 这里我使用的是mysql模块，该模块允许给typeCase属性设置一个回调函数。详见官网说明 connection.query({ sql: '...', typeCast: function (field, next) { if (field.type == 'TINY' && field.length == 1) { return (field.string() == '1'); // 1 = true, 0 = false } return next(); } }); 但这也意味着使用该方法的项目不能使用tinyInt(1)类型了，自行取舍吧~