pyinstaller黑色窗口一闪而过怎么去掉

2018年10月14日 08:32

默认情况下pyinstaller编译出的exe有cmd窗口。给它设置了-w选项,可以把它去掉。
为什么我加了,还是会出现一闪而过的黑色窗口
 

加上-w选项

 
python -m PyInstaller xxx.py -w
 

不要用os.system

 
os.system("xxx")  #会调用cmd.exe,所以会出现黑色窗口

#改用subprocess,不会出现黑色窗口
subprocess.Popen("xxx", close_fds=True)
 
《了凡四训》详解之改过之法
印光大师十念法(胡小林主讲第1集)
《寿康宝鉴》有声书

 

评论(0) 阅读(0)

pyinstaller编译出的exe被杀毒软件认为是木马

2018年10月14日 08:15

把python文件转为独立的exe,放在windows上运行。结果腾讯管家马上提示有可能是木马把它删除了
 
一脸懵逼,我良民,咋成木马了呢。思前想后,我做了什么,被认为很危险。原来我用了os.system。下面是演示
 

python文件

#xxx.py
import os
cmd="xxxxx"
os.system(cmd)
 

编译exe

#编译完成,系统提示发现木马
python -m PyInstaller xxx.py --onefile
 

解决方法

 
改用subprocess替代os.system
 
subprocess.Popen(cmd, close_fds=True)
 

为什么用了subprocess就没事了?

 
os.sytem属于独立进程间调用。subprocess外壳还是python属于内部进程。
 
 
《了凡四训》详解之改过之法
印光大师十念法(胡小林主讲第1集)
印光大师十念法(胡小林主讲第2集)
印光大师十念法(胡小林主讲第3集)
 
 

Tags: pyinstaller
评论(0) 阅读(1)

dnsmasq在docker中无应答

2018年10月01日 22:15

问题描述

制作了一个docker镜像,运行dnsmasq。域名解析竟然无应答, no servers cloud be reached
 
  • 发送请求解析域名
dig www.google.com @192.168.0.111 -p 53

; <<>> DiG 9.11.3-RedHat-9.11.3-4.fc27 <<>> www.google.com @192.168.0.111 -p 53
;; global options: +cmd
;; connection timed out; no servers could be reached
 
  • dnsmasq打印日志。从日志中发现缺少reply
[root@bogon ss]# docker-compose -f chinadns.yml up dns-dnsmasq

Starting ss_dns-dnsmasq_1 ... done
Attaching to ss_dns-dnsmasq_1
dns-dnsmasq_1   | dnsmasq: started, version 2.79 cachesize 150
dns-dnsmasq_1   | dnsmasq: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth no-DNSSEC loop-detect inotify
dns-dnsmasq_1   | dnsmasq: using nameserver 192.168.0.111#5354
dns-dnsmasq_1   | dnsmasq: read /etc/hosts - 7 addresses
dns-dnsmasq_1   | dnsmasq: query[A] www.google.com from 192.168.0.111
# 请求发送给了上游dns服务器,无后续reply。再去看上游dns服务器,发现已经解析出了ip
# 而dnsmasq还是无应答
dns-dnsmasq_1   | dnsmasq: forwarded www.google.com to 192.168.0.111
dns-dnsmasq_1   | dnsmasq: query[A] www.google.com from 192.168.0.111
dns-dnsmasq_1   | dnsmasq: forwarded www.google.com to 192.168.0.111
 

解决办法。

尝试了很多方法,很奇怪它为什么不能应答。dnsmasq也不大,放在宿主机上运行吧。
 
《了凡四训》详解之改过之法
印光大师十念法(胡小林主讲第1集)
百病之源

 

Tags: dnsmasq docker chinadns
评论(0) 阅读(106)

清静心:人以恶心对我

2018年9月22日 22:34

 
不放在心上
 

人以恶心对我

有人侮辱我、骂我、打我、轻贱我、看不起我、骗我、害我、防备我、怀疑我
 
我如何处之?
我的人生我做主,我的心态我做主
恶心害自己,我不接受,对我的伤害等于零
今天以恶心对我,明天消失,后天又以善心对我,一场空,我又何必造业。
帮助我消业障,提醒我因果
我已是局外人,而你被恶念束缚,心生怜悯
 
 

人以恶心对我的环境

有人造谣、诽谤,破坏我的环境
 
我如何处之?
被破坏说明缘分已尽,而我又无过错,往往是好事。
 

Tags: 清静心
评论(0) 阅读(145)

git清理历史成为干净库

2018年9月15日 14:34

目的

想把以前的历史清理掉,作为一个干净库使用

方法

删掉本地.git,再删除远程库。下面是真删除,尝试前先备份。
#删除本地分支
git branch -D xxx

#删除远程分支(除了master其它分支都删掉)
git push  :远程分支

#删本地git
rm -rf .git

#新建库
git init
git add -A

#关联远程仓库
git remote add origin http://xxxxxx.git

#强制提交并覆盖远程master
git push -f origin master
 
精神病为什么治不好
百病之源
此生必看的科学实验-水知道答案

 

评论(0) 阅读(187)

mysql存储引擎毫无疑问选择Innodb

2018年9月15日 12:25

网上观点

网上部分人在考虑如何选择MyISAM与InnoDB的依据是
* innodb 支持事务、行级锁. 适合写多读少
* myisam 表锁,适合读多写少
 

实际测试下查询速度

1千万(InnoDB)
select *        21秒
select id=xxx   0.026秒
count(id)       15.71秒(第一次16.71,第二次0秒,插入一条后16.476秒)
count(username) 16.956秒
avg(id)         18.41秒

1千万(Myisam)
select *        8.389秒
select id=xxx   0秒
count(*)        0秒
count(username) 1.643秒
avg(id)         3.793秒

myisam-->innodb 52.200秒
确实MyISAM比InnoDB快了3倍
 
可问题是实际中,都是通过索引分批取数据,有谁有一次取那么多的数据呢?而分批取数据性能都差不多。
 

存储引擎特性对比

下面是官方网站上mysql8.0的特性。可以看出MyISAM特性,InooDB都有,没有必须选择MyISAM的理由
| Feature                      | MyISAM       | InnoDB       |
| B-tree indexes               | Yes          | Yes          |
| Backup/point-in-time 恢复    | Yes          | Yes          |
| Cluster database support     | No           | No           |
| Clustered indexes            | No           | Yes          |
| Compressed data              | Yes (note 2) | Yes          |
| Data caches                  | No           | Yes          |
| Encrypted data (note 3)      | Yes          | Yes          |
| Foreign key support          | No           | Yes          |
| Full-text search indexes     | Yes          | Yes (note 5) |
| Geospatial data type support | Yes          | Yes          |
| Geospatial indexing support  | Yes          | Yes (note 6) |
| Hash indexes                 | No           | No (note 7)  |
| Index caches                 | Yes          | Yes          |
| Locking granularity          | Table        | Row          |
| MVCC                         | No           | Yes          |
| Replication support (note 1) | Yes          | Yes          |
| Storage limits               | 256TB        | 64TB         |
| T-tree indexes               | No           | No           |
| Transactions                 | No           | Yes          |
| Update statistics for data dictionary YesYes
 

官方网站怎么说MyISAM?

#原文
MyISAM: These tables have a small footprint. Table-level locking limits the performance in read/write workloads, 
so it is often used in read-only or read-mostly workloads in Web and data warehousing configurations.
#意思
MyISAM应用范围比较小。它是表级锁,对并发读写有限制。适合只读或者大部分是读的web应用或者配置性的数据仓库。
 

数据损坏

InnoDB会自动恢复,MyISAM需要定时检查
 

我的结论

* 从查询速度上,实际中是分批取数查询数据差不多
* 从特性上,InooDB是MyISAM的超集
* 从功能上,InooDB功能更强
 
所以网上说读多写少选择MyISAM是人云亦云。
当然存在肯定有理由,为了兼容性,还是什么?
 
此生必看的科学实验-水知道答案
精神病为什么治不好
百病之源

 

Tags: myisam
评论(0) 阅读(193)

思考大表统计的优化策略

2018年9月15日 10:02

前言

以InnoDB表的count()统计为例子
 

方法一、直接count,全表扫描

 
* 分析
#一千万条数据count()耗费几十秒,基本不用干活
select count(*) from user
 

方法二、分段count,全表扫描转变为范围扫描

加上where条件,将全部查询,拆分成多个小范围查询。
#全表扫描
select count(*) from user;

#范围扫描
select count(*) from user where id < 1000000;
select count(*) from user where id>=1000000 and id < 200000;
 
实际中需要打开多个数据库连接,实际操作不是很好。
 
当然分表也属于这类方法
 
* 原理
大问题拆成多个小问题,将压力分散。
 
* 分析
如果是同一张表,需要打开多个连接(多个进程)
如果分库了,需要连接多个数据库
虽然能减少时间,但是不能减小压力,count()次数多了,系统也得嗝屁
 

方法三、增加tinyint类型字段并建立二级索引用于统计

 
二级索引key是索引列,value是主键,一个数据页上可以存储更多数据,减少了分页于页内移动
 
#加了之后再统计,mysql解析器会自动选择二级索引进行count
select count(*) from user
 
* 原理
利用二级索引减少io
 
* 分析
能够减少时间,也能减小io压力,但是时间还是挺长的,我的机器上一千万数据从5秒编成了1秒,1秒还是比较长
假如加上where条件呢,这个方法就用不上了
 

方法四、维护一张统计表

凡事预则立,不预则废,设计时加一张tablename_stats表(两个字段key,value),平时就维护好统计数据,增加时加1,删除时减1。
 
key value 
count                   1111
hash值(表名+where条件) 1111
 
* 原理
提前准备
 
* 分析
毫无压力,效果完美
需要提前预测好可能的统计以及条件
缺点存在统计数据与实际不一致,在大数据量情况下,也不算什么问题
 

总结

最终发现还是类似myisam维护一个计数器是最好的方法。
只是我们扩展了功能,加了where条件也提前计数
 
 
《了凡四训》详解之改过之法
印光大师十念法(胡小林主讲第1集)
此生必看的科学实验-水知道答案

 

Tags: 大数据
评论(0) 阅读(177)

myisam锁表机制

2018年9月15日 06:34

 锁表机制

* 锁机制
a.加锁读(共享锁):不会阻塞读请求(select, insert),阻塞写(update, delete)请求
b.加锁写(独占锁):阻塞其它读写(select, delete, insert, update)请求
 
* 锁耗时多长?
取决于sql耗时。控制好sql耗时,锁表的问题并不大。
 

测试数据

生成1000万条测试数
表user(id, username, password, age, sex)
存储引擎MyISAM,id建立索引
 

加锁读,select,insert不阻塞,update,delete阻塞

打开两个客户端
客户端1全表扫描
select * from user
 
客户端2测试阻塞
select * from user limit 10;    #结果不阻塞

insert into user(username, password, age, sex)
values("aaaaa", "bbbb", 10, 1); #结果不阻塞

update user set username="aaa" where id =90001;  #结果阻塞

delete from user where id =10000006  #结果阻塞
 

加锁写,select,insert,update,delete都阻塞

 
客户端1全表扫描写
update set username="aaaaaaa"
where username="不存在的值让sql扫描全表"
 
客户端2测试阻塞
重复上面select, insert, update, delete结果都阻塞
 
此生必看的科学实验-水知道答案
《了凡四训》详解之改过之法
印光大师十念法(胡小林主讲第1集)

 

评论(0) 阅读(180)

flask自动重连数据库

2018年9月12日 07:43

情况描述

flask部署到服务器后,日志中经常出现错误
sqlalchemy.exc.OperationalError: (pymysql.err.OperationalError) (2006, "MySQL server has gone away (ConnectionResetError(104, 'Connection reset by peer'))")
 
看下mysql日志,大量的超时导致的连接中断
...
2018-09-10  6:45:41 768 [Warning] Aborted connection 768 to db: 'xxx' user: 'xxx' host: '172.22.0.2' (Got timeout reading communication packets)
 

问题原因

原因就是因为连接超时,数据库把它中断了,详细参见官方文档.
https://dev.mysql.com/doc/refman/8.0/en/communication-errors.html
 

起因

  • 查看数据库配置。不要混淆全局配置与会话配置
show global variables like '%timeout%'

connect_timeout      5
interactive_timeout  28800
wait_timeout      600
 
  • 配置文件my.cnf
connect_timeout         = 5
wait_timeout            = 600
 

错误复现

mysql错误日志两次中断间隔时间都大于600秒,有可能是该参数引起,将它设置小点看看,能否复现问题
set global wait_timeout=10
 
设置后,问题又出现了,可以缺点就是该参数引起的。
 

自动重连实现

无论wait_timeou设置多大,总会出现超时,该怎么避免呢?简单方法是定时重连接.
 
flask已经提供了重连参数。连接超过一定时间就将它回收。
SQLALCHEMY_POOL_RECYCLE=7200   # 默认2小时。该值一定要比数据库wait_timeout小,否则它不起作用,上面就是这个原因导致的
 
当然这个方法不会帮我们处理网络异常导致的连接失效时重连
 
《了凡四训》详解之改过之法
印光大师十念法(胡小林主讲第1集)
此生必看的科学实验-水知道答案

 

Tags: flask
评论(0) 阅读(231)

sysbench测试mysql性能瓶颈

2018年9月06日 05:56

前言

任何系统,业务越来越繁忙,最终都会遇到性能瓶颈。能够提前知道系统大概的瓶颈,是很重要的。下面介绍一个测试工具sysbench
 

安装

yum install sysbench
#下面测试中版本是1.0.9
 

github

https://github.com/akopytov/sysbench
 

测试mysql

sysbench --test=/usr/share/sysbench/oltp_insert.lua
--mysql-host=127.0.0.1
--mysql-port=3306
--mysql-user=root
--mysql-password=111111
--mysql-db=mytest
--db-driver=mysql  prepare
 
  • * 参数选项
--test 指定测试所用lua脚本
--mysql-host
--mysql-port
--mysql-user
--mysql-password
--mysql-db
--db-driver=mysql  #指定db类型
prepare 测试前准备工作
run 正式测试
cleanup 测试后删掉测试数据
 
  • * lua脚本的参数选项
详细参数看lua脚本/usr/share/sysbench/oltp_common.lua
下面是常用参数
--mysql_storage_engine=innodb   #表引擎
--table_size=10000              #表大小
--tables=10                     #表数量
 
《了凡四训》详解之改过之法
印光大师十念法(胡小林主讲第1集)
此生必看的科学实验-水知道答案
 

Tags: sysbench
评论(0) 阅读(256)