MinIO集群CPU占用太高

之前搭建的MinIO集群,用来测试公司的业务图片。今天登陆上去一看,发现集群的CPU占用很高,被Minio全占完了,100%。

因为集群平时不做其它事情,负载也完全很低,出现CPU 100%的情况非常异常。检查了一圈也没啥可疑的,唯有CPU一直处于100%。

无奈只能更换MinIO了,去他们官网上又重新下了一份回来,当前版本为:minio version RELEASE.2020-10-28T08-16-50Z,重新启动集群后,CPU立马降下来了。

之前在他们的github上看到也有人提出CPU占用问题,官方回复都予以修复,看来之前也确实出现过同样问题,只是时间节点跟我的情况对不上,所以干脆重新下载了一份新的回来,没想到问题就解决了。

京东的这个套路有点骚

十一月一日之前,在京东定了一块手表,正好当时有活动,预定送充精工充电宝一个,就付了一百块定金,到十一月一日零时付完尾款就可以,并且预定有优惠,显示到手价为3209,也比平时便宜了不少。但是让人奇怪的人,预定后没几天,主宣传图显示到手价为3109,整整降了一百块,那我这个是按照到手价3109算还是按3209算?


今天问了客服,告诉我说到手价3109需要到首页抢优惠券,抢到券才可以享受3109的价格,但是在整个产品页面上只字未见什么抢优惠券的事情。


好吧,你这样跟我解释,我就勉强接受,只能说你这个套路有点骚,但接下来的事情,就更骚了。


我问客服为啥当时宣传图上显示的前1111名赠送精工充电宝并没有赠送,因为我当时付完定金以后,产品页上显示只有4个人已经预定,并且几天后才多了一个人显示五个人已经预定,客服告诉我说以实际下单为准,并且说这个赠品跟前1111名没有任何关系。我就奇了怪了,照你这么说,那你们就可以随意在主图上宣传最后以订单为准了?你主图上写买表送上海一套房,结果也以订单为准了?这不就是摆明了欺诈吗?


最后客服扔给了我一个客服电话,让我五点钟之前打,我也就呵呵了,一会出去打电话问问。

20201106更新:原来应该前两天更新的,但是考虑到在没有拿到货前更新有点不稳妥,所以就等到了今天。

经过跟京东的客户沟通,了解到原来精工的手表是由上海的一家精工代理商发货的,而并不是京东自己。之前页面上的沟通客服,完全就是供应商自己的人,难怪不认账了。

事情原由跟京东客服说清楚后,客服很直接的问我有没有当时截图,我说没有,谁会想到会有这种事情去截图呢,客服二话不说告诉我24小时内给我答复。结果第二天就给了电话确认,供应商补发赠品。这里是要给京东客服点个赞的,靠谱。

删除总是弹广告的flash helper service

flash helper service是flash.cn的服务,这里并不是flash自身的服务,主要是因为flash在国内被代理了。

flash helper service的主要功能就是给你推广告,这个是比较恶心的,各种不堪入目的广告,更为关键的是,点开之后什么都没有,所以必须要反它干掉。

打开任务管理器,找到flash helper service进程,右键“打开文件所在位置”,然后杀掉进程,再把文件所在目录删掉。因为有些控件是在使用中,你是删不掉的,但是没有关系,只要把flash helper service这个程序干掉就行了。

如果你有代理,可以挂上代理去adobe的官网下载个安装程序回来,注意:下载的时候地址栏会是带有cn目录,有代理的情况下把cn换成tw,类似这种地址:https://get.adobe.com/cn/flashplayer/ 把里面的cn换成tw,你就可以打开繁体页面,放心的下载回来安装就可以了。

MinIO集群搭建部署

环境:VMware虚拟机
节点1:10.0.0.1
节点2:10.0.0.2
节点3:10.0.0.3
节点4:10.0.0.4

因为MinIO官方建议最少4个节点,这里是测试,所以就一个节点一块盘。
在第一次实施过程中遇到了个坑,其实也不算是坑,而是没有仔细操作,只是想偷懒。MinIO要求的是盘,而我这里使用的是一个目录,单机运行的时候没有问题,但是在集群的时候就不行了,提示

Disk /data/minio_data is a root disk. Please ensure the disk is mounted properly, refusing to use root disk.


主要问题就是MinIO数据存储使用的是目录,而不是重新挂载的硬盘。
重新在VMware里添加一块硬盘挂载上系统就可以解决这个问题。


大概的步骤就是:
1、lsblk查看硬盘名称,比如/dev/sdb b在这里是个序号,你系统硬盘多,就顺延,比如到e之类。
2、新硬盘创建分区:fdisk /dev/sdb,根据提示输入n,然后后面只管确认就行,整块sdb就会被分为一个区。
3、格式化新分区,我这里使用的是centos7,格式为xfs,mkfs.xfs /dev/sdb,具体什么格式,你可以查看原系统的,lsblk -f,或者df -Th都可以看到分区格式。
4、挂载:mount /dev/sdb /data1

阅读更多

Python 截取txt中固定字段并去除重复行

看了一段时间的Python教程,正好前两天群里放出来一个txt文件,我就顺便拿过来练练手。

txt文件简介:

1、每行内容都是重复的

2、内容分段一致,用|分隔开,类似于A|B|C|D|E

需求:取出固定字段,比如A、C、E,并去除重复的行。

思路:

1、重复的内容比较好处理,直接读出一行去到原文件里比较,如果存在,就存放到新的txt文件里。

2、取出固定字段,这个用列表来实现,读出一行,存到列表里。

第一次完整的写代码,比较乱,直接贴上来,有用拿去好了,GITHUB账号还没有申请,先丢这里好了。

import os,sys,time
start=time.time()
os.chdir('d:')
print (os.getcwd())
os.remove('new.txt')
os.remove('final.txt')
f=open('test.txt',encoding='utf-8')
for n in f.readlines():
    m=n.split('|')
    b=open('new.txt','a',encoding='utf-8')
    b.write(str(m[8])+'\t'+str(m[10])+'\t'+str(m[22]))
    #print(m[8],m[10],m[22])
    b.close()
f.close()
c=open('final.txt','a',encoding='utf-8')
h=open('new.txt',encoding='utf-8')
for a in h:
    if a in h:
        c.write(str(a))
c.close()
end=time.time()
print('time used:',end-start)

2020.9.15更新:
因原文件中有个别数据是单行,所以造成上面程序在运行时无法全部整理整个文件。单行不重复文件处于中间,整理后的文件就终止在了这个单行的位置。

这里使用python的set()函数,创建一个非重复的列表,增加一个:

bk=set()
然后循环遍历的代码改成:
for i in h:
if i not in bk:
bk.add(str(i))
c.write(str(i))
意思就是不在bk里面,就添加进bk,然后写进txt里。
这里同时也发现一个问题,python在for循环的时候,是会将被循环文件里的数据拿出来的,也就是被循环文件缺少一行。

MySQL占用大量CPU资源到100%

生产上的MySQL5.6的库,一直都很正常的运行,从昨天下午开始,服务器CPU资源100%,开始我还以为是其它应用占用了CPU资源,一段时间后应该会放开,直到今天早上,CPU还仍然是100%,这就让我很疑惑了。

赶紧上去查看一下:

#top

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

15232 mysql 20 0 2779m 2.3g 0 S 197.1 29.1 80573:31 mysqld

果然,CPU被MySQL占完了,业务部门也反应系统查询很慢。

我就呵呵了,这平时跑着都正常,怎么突然就100%了。

mysql>show processlist;

然后就发现某台服务器正在用一个我没见过的账号在查询,状态一直是Sending data,而且有好几条。

去mysql-slow.log里翻一下,嗯,是有这么一条select语句。

二话不说,问开发有没有用那个MySQL的账号,回答说有,直接把SQL语句丢过去,然后在MySQL里kill掉那些一直Sending data的查询:

mysql>kill xxxxx;

进程号在你show processlist的时候就有,直接干掉,然后再出来top一下,嗯,CPU已经恢复正常了。

ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance

公司的测试数据库,开发的在上面跑脚本,把库资源全占完了,要我把库重启,我懒得去重启,就直接杀了oracle的进程,结果还是不行,就只能去重启库了:

$sqlplus / as sysdba

SQL>shutdown abort

SQL>startup

ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance

ORA-03113:end-of-file on communication channel

ORA-32004的错误,按照老外的方法:

sql>alter system reset log_archive_start scope=spfile;

完美解决,也有说是直接清理干净日志系统就可以,反正这里也是要清理的,不然ORA-03113错误没法解决。

ORA-03113:end-of-file on communication channel,去alert.xml里看,有关于闪回区日志占满的情况,这里就直接清理好了。

$rman target /

DELETE force archivelog ALL completed before ‘SYSDATE’;

然后再startup,这里就成功启动了。