东东东 陈煜东的博客

2 / 20

docker 容器自定义 hosts 网络访问

在搭建 Drone CI 服务的时候,拉取git代码出现了网络不通。

+ git init
Initialized empty Git repository in /drone/src/testgit.com/root/demo1/.git/
+ git remote add origin http://testgit.com:10080/root/demo1.git
+ git fetch --no-tags origin +refs/heads/master:
fatal: unable to access 'http://testgit.com:10080/root/demo1.git/': Couldn't resolve host 'testgit.com'
exit status 128

也是到 Drone 的论坛问了 http://discourse.drone.io/t/help-git-clone-with-custom-extra-hosts/217。 看来需要自己设置网络问题,没有办法通过 docker-compose.yml 文件来进行设置。

普通的 Docker 容器解决方案

在 docker-compose.yml 中增加 extra_hosts 关键字就可以将数据写入到容器的 /etc/hosts

version: '2'

services:
  drone-server:
    image: drone/drone:latest
    ports:
      - 8100:8000
    extra_hosts:
      - "mygit.com:10.123.123.130"
    volumes:
      - ./drone:/var/lib/drone/
    restart: always
    environment:
      - DRONE_OPEN=true
      - DRONE_DEBUG=true

Drone CI 的情况

Drone CI这个情况比较麻烦。是在Drone agent容器里面又启动了一个容器,这个时候没有关于extra_hosts设置给子容器。于是子容器无法访问特定的域名。

修改 hosts 文件失败

本来想设置添加一个 hosts 文件到镜像中的。但是发现一只失败,无法写入成功。

FROM plugins/git

ADD ./hosts /etc/
RUN cat /etc/hosts

不过这条路走失败了。

hosts文件其实并不是存储在Docker镜像中的,/etc/hosts, /etc/resolv.conf/etc/hostname,是存在/var/lib/docker/containers/(docker_id)目录下,容器启动时是通过mount将这些文件挂载到容器内部的。因此如果在容器中修改这些文件,修改部分不会存在于容器的top layer,而是直接写入这3个文件中。容器重启后修改内容不存在的原因是每次Docker在启动容器的时候,Docker每次创建新容器时,会根据当前docker0下的所有节点的IP信息重新建立hosts文件。也就是说,你的修改会被Docker给自动覆盖掉。

摘录自:https://wongxingjun.github.io/2016/04/06/Docker%E4%BF%AE%E6%94%B9hosts/

问了同事,一般很多容器的做法是,通过将hosts 文件写入容器,然后在容器启动后, cat /data/hosts > /etc/hosts到,然后再执行命令。

我觉得这个方法不适合我,因此我重新寻找新的方法。后面找到了利用 DNS 服务来规避。

搭建 dnsmaq DNS 服务

将需要配置的 hosts 写入到 /etc/hosts 中。

在虚拟机或者特定服务安装 dnsmaq 服务。

yum install dnsmasq -y

touch /etc/dnsmasq.hosts

# 重启
service dnsmasq restart

# 测试一下是否可以查询到域名
dig @127.0.0.1 testdomain.com

使用 Docker 的 DNS 解决

vim /etc/docker/daemon.json

{
    "dns": ["10.123.12.14", "8.8.8.8"]
}

将刚刚的 DNS 服务器 IP 写入到配置中,追加一个字段 dns。如果还有其他的 DNS 服务器,那么就写入在数组中写入其他的 IP。

重启一下 Docker 服务。

service docker restart

Docker 容器测试网络

这个是我的容器
docker run --rm -e DRONE_REMOTE_URL=http://mydomain.com:10080/root/demo1.git plugins/git

或者
docker run busybox nslookup google.com

参考文章

声明:未经允许禁止转载 东东东 陈煜东的博客 文章,谢谢。如经授权,转载请注明: 转载自东东东 陈煜东的博客

本文链接地址: docker 容器自定义 hosts 网络访问 – https://www.chenyudong.com/archives/docker-custom-hosts-network-via-dns.html

分类: DevOps

website impress 网站评分插件

抽空写了个 Google Chrome的插件。github地址 https://github.com/daoiqi/website-impress

Chrome 插件下载地址: https://chrome.google.com/webstore/detail/fjfddiiaeehjogpabflgicipdgdfljof/

在互联网上经常充斥着一些垃圾网站,网站缺少真实的内容或者带有欺骗性的内容,欺骗用户的感情,影响用户的使用。

** 这类网站应该被揪出来,并且不建议逗留。 **

目前无意做一个点评网站,本插件的数据是利用百度口碑的数据来展示的。

如果有什么好的点评数据,欢迎给我留言。

评分说明

从百度口碑获取好评率。好评率理论上从 0-100% 的。 由于百度口碑的打分最低是一星,所以好评率最低是 20%

数字太大不方便看,因此从0-100的分数映射为 0-10分。

  • 0-59 红色,好评率在0-59%之间,实际最低应该是20%。对应就是一星~三星之间。
  • 60-79 橙色,好评率在60%-79%之间。对应在三星~四星之间。
  • 80-100 绿色,好评率在80%-100%之间。对应在四星和五星。

demo

demo2

demo1

声明:未经允许禁止转载 东东东 陈煜东的博客 文章,谢谢。如经授权,转载请注明: 转载自东东东 陈煜东的博客

本文链接地址: website impress 网站评分插件 – https://www.chenyudong.com/archives/website-impress.html

分类: Web 开发

rinetd – Linux tcp port forward

在寻找一个 Linux 的TCP 端口转发程序,大部分都是使用 iptables 来使用的,但我觉得 iptables 不是很好用,主要是不熟悉他的命令。

上网找了一个程序 rinetd,写个配置文件,可以后台运行,很简单。

下载地址:https://centos.pkgs.org/6/nux-misc-x86_64/rinetd-0.62-9.el6.nux.x86_64.rpm.html

教程 https://www.boutell.com/rinetd/

配置很简单vim /etc/rinetd.conf

# config rules


# 设置允许的请求来源
# allow 206.125.69.*

# 配置端口转发信息
# bindaddress bindport connectaddress connectport
0.0.0.0 23 206.125.69.81 23

service rinetd restart 重启一下服务。

声明:未经允许禁止转载 东东东 陈煜东的博客 文章,谢谢。如经授权,转载请注明: 转载自东东东 陈煜东的博客

本文链接地址: rinetd – Linux tcp port forward – https://www.chenyudong.com/archives/rinetd-linux-tcp-port-forward.html

分类: Linux 软件

利用 Docker 镜像 gogs 搭建一个私有的 git 服务

本文是为了构建一个私有的持续集成服务而准备的。

利用 Docker 来方便构建,不怕环境错乱,同时也帮忙配置好了一些东西。

Docker 安装准备

需要有一个 Docker 环境, 简单的提及一下 Docker 的事项。

yum install docker
pip install doker-compose

更多参考 https://www.chenyudong.com/archives/docker-practice.html

gogs的搭建是参考https://zhuanlan.zhihu.com/p/24896056

说一下文中的

    links:
        - mysql:mysql

在配置 gogs 的时候,输入数据库地址,需要输入 mysql:3306,被这个给绕晕了。

同步 git 仓库

因为不是提供一个稳定的仓库给大家推送,因为网络的原因,我的CI服务器无法直接访问git仓库,因此单独搞一个git服务,那么需要将代码同步过来。

看到 这篇文章,觉得思路不错。

# 首先先下载过来
git clone --mirror git@github.com:git_user/project.git

# 先拉取一下代码
cd project.git
git fetch -q --all -p

# 推送代码到另外一个服务上
git remote add another_git http://git.com/git_user/project.git


# 周期任务
sudo vi /etc/cron.d/sync_git_repos
*/5 * * * * app cd /path/to/project.git && git fetch -q --all -p && git push another_git --all

接下来配合文档服务和CI服务,进行持续集成。

声明:未经允许禁止转载 东东东 陈煜东的博客 文章,谢谢。如经授权,转载请注明: 转载自东东东 陈煜东的博客

本文链接地址: 利用 Docker 镜像 gogs 搭建一个私有的 git 服务 – https://www.chenyudong.com/archives/gogs-git-docker-service.html

分类: DevOps

ReadTheDocs 私有部署搭建安装

readthedocs 这个网站还真不错,提供了文档托管服务,让很多开源项目的文档变得很完善。

网上很少有Read The Docs 的一些私有部署文章,希望这篇《Read The Docs 私有部署安装》能帮助到大家,也一起交流交流。

想到有一些私有项目,目前还达不到开源的标准,但内部需要有一个文档服务,之前是利用 Nginx + Sphinx 搭建简单的 HTML 网页来展示的,缺少一些版本的控制,因此想引入 Read The Docs 开源版来进行部署。

很棒的是 Read The Docs(下文会有 RTD 来进行缩写) 提供开源的版本,官方也有一些部署的文档,但是只能说马马虎虎,会遇到一些和想象中不那么美好的事情,这里记录一下,给大家填填坑。

安装

一些步骤参考官方的网页https://docs.readthedocs.io/en/latest/install.html

其中说一个很重要的步骤就是

virtualenv rtd
cd rtd
source bin/activate

因为 Read The Docs 会使用大量的 Python 类库,所以这里建议单独独立出一个环境来,当然也可以用 Docker 版本。

我这就出现了 RTD 的 docker-py 和 系统的 docker-compose 冲突的情况。

  File "/root/readthedocs/readthedocs.org/readthedocs/doc_builder/environments.py", line 16, in <module>
    from docker import Client
ImportError: cannot import name Client

HTTP 网络代理

这里是处理起来耗费了大量的时间的。个人不懂 Django,想打印一些日志也好不难,设置了一些 DEBUG 级别,也没有遇到想要的一些日志。

由于机器没有直接的外网访问权限,因此需要配置 http 代理,这里有说明 简单的 http 代理设置

还有需要拉取 git 代码,git的代码也是需要使用代理的。

git clone http://github.com/sphinx/sphinx
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

网上说是git config --global http.postBuffer 524288000,可以我这一直没有成功,我一直在想我是不是我使用的代理有问题,后来换成一个 Squid 的代理 是没有出现了。

艰辛的调试过程

以前网页一直是已触发构建状态,就是一直没有看到什么失败的信息啊,也不动,心里着急,一直尝试了很久了的,都放弃了。

看到日志,加一些日志都不出现,最后是raise BaseException('eee')二分搜索,才在网页上看到异常信息的。

触发编译文档

利用异常,然后发现了报错的地方,居然都是因为服务要进行一次 HTTP 服务,被设置了代理,无法访问,所以把域名给排除代理了。不过此时的编译是阻塞型的,网页无法快速返回。接下来就是要看看要怎么异步,都已经配置了 Celery 的信息了。终于看到编译过程的真身了,兴奋不已,离成功已经不远了。

构建成功

构建成功

Celery 异步触发构建

一直寻找为什么 Celery 没有异步起作用,直到根据代码一层一层深入 Celery,发现有个很重要的变量CELERY_ALWAYS_EAGER

"""
If the :setting:`CELERY_ALWAYS_EAGER` setting is set, it will
        be replaced by a local :func:`apply` call instead.
"""
app = self._get_app()
if app.conf.CELERY_ALWAYS_EAGER:
    return self.apply(args, kwargs, task_id=task_id or uuid(),
                      link=link, link_error=link_error, **options)


之前就一直注意到EAGER这个配置,上网搜索信息,还以为是语法糖效果呢,可以不用显示的使用task.delay()。现在看注释才明白,CELERY_ALWAYS_EAGER如果为True,那么 Celery 不会使用异步模式,而是在本地上下文采用阻塞执行,所以要使用异步执行,那么需要将这个值设置为CELERY_ALWAYS_EAGER = False

配置完 redis 的信息,然后执行一些命令。

C_FORCE_ROOT=1 ./manage.py celeryd -E --loglevel=DEBUG   # 启动 Celery Worker   
./manage.py celerybeat  --verbosity=3   # 启动 Celery 周期任务事件
./manage.py celerycam                   # celery快照?

运行正常

为成果庆祝一下。

构建成功

构建成功

周期任务

待补充

Docker 编译环境

待补充

相关文章

声明:未经允许禁止转载 东东东 陈煜东的博客 文章,谢谢。如经授权,转载请注明: 转载自东东东 陈煜东的博客

本文链接地址: ReadTheDocs 私有部署搭建安装 – https://www.chenyudong.com/archives/readthedocs-private-install.html

分类: DevOps

Docker 实践记录

记录一下使用的 Docker 的辛苦过程。

Docker 使用的范围越来越广,我最看重的就是环境隔离,和环境整体打包服务,不用再自己的本地环境上编译。

本文以 CentOS 7 来作为记录过程,其他的发行版类似,就一些系统级别的命令可能不合适。

安装

yum insatll docker

重启

systemctl daemon-reload
systemctl restart docker

本地镜像加速

出现

root@VM_96_130_centos tmp]# docker pull mysql:5.7
Trying to pull repository docker.io/library/mysql ... 
Pulling repository docker.io/library/mysql
Error while pulling image: Get https://index.docker.io/v1/repositories/library/mysql/images: dial tcp 52.207.59.176:443: getsockopt: network is unreachable
Error while pulling image: Get https://index.docker.io/v1/repositories/library/mysql/images: dial tcp 52.207.59.176:443: getsockopt: network is unreachable

我这里使用的是腾讯云,因此我这里的是镜像加速和下载

vim /usr/lib/systemd/system/docker.service
ExecStart=/usr/bin/docker-current daemon \
          --exec-opt native.cgroupdriver=systemd \
          --registry-mirror=https://mirror.ccs.tencentyun.com \
          -g /data/docker/ \
          $OPTIONS \
          $DOCKER_STORAGE_OPTIONS \
          $DOCKER_NETWORK_OPTIONS \
          $ADD_REGISTRY \
          $BLOCK_REGISTRY \
          $INSECURE_REGISTRY

顺便更改一下 docker 镜像的路径,防止系统根目录太小。

网上也有说 /etc/default/docker为啥不起作用的

HTTP 代理

利用 docker build -t xxx . 出现一些错误

Ign http://archive.ubuntu.com trusty InRelease
Ign http://archive.ubuntu.com trusty-updates InRelease
Ign http://archive.ubuntu.com trusty-security InRelease
Err http://archive.ubuntu.com trusty Release.gpg
  Cannot initiate the connection to archive.ubuntu.com:80 (2001:67c:1360:8001::21). - connect (101: Network is unreachable) [IP: 2001:67c:1360:8001::21 80]
Err http://archive.ubuntu.com trusty-updates Release.gpg
  Cannot initiate the connection to archive.ubuntu.com:80 (2001:67c:1360:8001::21). - connect (101: Network is unreachable) [IP: 2001:67c:1360:8001::21 80]
Err http://archive.ubuntu.com trusty-security Release.gpg
  Cannot initiate the connection to archive.ubuntu.com:80 (2001:67c:1360:8001::21). - connect (101: Network is unreachable) [IP: 2001:67c:1360:8001::21 80]

修改 Dockerfile ,增加http代理

FROM ubuntu:14.04
MAINTAINER Kevin Littlejohn <kevin@littlejohn.id.au>, \
    Alex Fraser <alex@vpac-innovations.com.au>

# 这个是可用的
ENV http_proxy=http://xx.xx.xx.xx:6788/
ENV https_proxy=http://xx.xx.xx.xx:6788/


# 网上有这么说的,这个是不能用于 ubuntu的agt-get。
ENV HTTP_PROXY=http://xx.xx.xx.xx:6788/
ENV HTTPS_PROXY=http://xx.xx.xx.xx:6788/

目前没有找到一个说法,http_proxy 是否应该大写。应该是不同的程序读取的环境变量不一样,我看大部分都是小写,最好的方法是都设置。

有一些讨论:http://unix.stackexchange.com/questions/212894/whats-the-right-format-for-the-http-proxy-environment-variable-caps-or-no-ca

常用的命令记录

docker build

# 编写 Dockerfile 文件
docker build -t docker-proxy .

docker images

查看镜像

docker exec

# 进入容器内部
docker exec -it 容器id /bin/bash

docker run

# 打开镜像看看
# 因为有时候直接启动会被退出了。
docker run -i -t ubuntu:14.04 /bin/bash

docker-compose

pip install docker-compose
# 编写 docker-compose.yml 文件
docker-compose up -d 

其他的系统也有依赖 docker 的,出现了

  File "/root/readthedocs/readthedocs.org/readthedocs/doc_builder/environments.py", line 16, in <module>
    from docker import Client
ImportError: cannot import name Client

那么其他使用 virtualenv 来解决单独的部署问题,让默认的系统能够正常使用。

声明:未经允许禁止转载 东东东 陈煜东的博客 文章,谢谢。如经授权,转载请注明: 转载自东东东 陈煜东的博客

本文链接地址: Docker 实践记录 – https://www.chenyudong.com/archives/docker-practice.html

分类: DevOps

git bash 遇到的一些问题

使用了 git windows 客户端遇到的一些问题记录。

$ git --version
git version 2.11.0.windows.1

退格键无法工作

升级了一下git的 Windows 客户端,默认操作都是使用 git-bash.exe 来进行命令行的使用的。但是例如 PyCharm 里面带的 Terminal 用的是 git-bash.bat 这里面的效果。遇到了很尴尬的问题,方向键和退格键都无法使用。

看了这个帖子修改了一下可以使用方向键和退格键了。 http://superuser.com/a/683405

git-bash.bat 开头的一些地方加了下面的一段话。

SET TERM=cygwin

git bash 中文乱码

ls 文件的时候出现

''$'\345\217\221\344\277\241\346\201\257''.txt'

类似的编码,使用一下的东西,好像也没怎么改动。在git-bash.exe 中就中文显示正常了,但是 PyCharm 里面的那个还是有问题。

# disable/enable 8bit input
set input-meta on
#set output-meta on
set output-meta on
set convert-meta off
#set convert-meta off

声明:未经允许禁止转载 东东东 陈煜东的博客 文章,谢谢。如经授权,转载请注明: 转载自东东东 陈煜东的博客

本文链接地址: git bash 遇到的一些问题 – https://www.chenyudong.com/archives/git-bash-windows-keng.html

分类: 实用技巧

一个有趣的微信公众账号 浦发褥积分红包

浦发信用卡有一个在线消费送红包的活动,红包里面有浦发信用卡的积分。一个红包和分享给五个好友,每天最多可以获取好友的15个红包。

面对这个活动,周围的好友都是采用拉微信群,群里面有15个好友,加上自己是16个人。一时间感觉大家好有头脑,褥羊毛的姿势还挺厉害。

期间,我一直想利用微信机器人,利用web微信的协议来点击群里的浦发红包,但是一直需要“在微信的客户端里打开”给折磨了很久,把cookie搞过来了也不管用。还得再研究研究。

后来有人推荐了一个公众账号《爱卡爱羊毛》,我觉得她的思路不错。她只做一个转发平台,有人给他发一个红包链接(可以被5个用户打开),她会给用户发送5个红包链接。理想情况下,只要假设用户稳定,每天分享的和收红包的应该是收支平衡的,因为想要获得红包,必须先分享红包。

什么场景会打破平衡?

用户不断的分享红包,但是忘记抢别人的红包了。这种情况,只是把红包给浪费了,后台应该无法记录红包是否有被打开过,如果根据是否有点击来判断,然后来跳转网址,工作量会比较大一些,但应该还是可以做的。可能还是要结合业务场景。

用户提前将红包分享给了其他朋友,然后又给公众账号发送了一个红包(可能只剩下4个了),但是却获得5个红包。这个时候就会破坏平衡了。面对这个问题,她的做法是增加举报功能,让这个用户被封号。

好想法

我觉得这个公众账号的思路非常棒,相当于一个平台的共享经济。她的这个功能感觉也有复用的空间能力,看看能不能联系上开发人员,看看能否一起开源维护。

声明:未经允许禁止转载 东东东 陈煜东的博客 文章,谢谢。如经授权,转载请注明: 转载自东东东 陈煜东的博客

本文链接地址: 一个有趣的微信公众账号 浦发褥积分红包 – https://www.chenyudong.com/archives/spdb-earn-points-in-wechat-public-platform.html

分类: 生活

Python 的 json 在 Nuitka 下性能好差

在商业项目中使用了 Nuitka 来进行源码的编译和保护。结果用户反馈使用的 HTTP 请求好慢,数据量一大就超时了。

案发现场

将代码在本地运行,进行 strace 发现好慢。

     0.000136 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 22), ...}) = 0 <0.000008>
     0.000050 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa5d83f8000 <0.000019>
     0.000056 write(1, "\r\n", 2)       = 2 <0.000017>
     0.000048 write(1, "\r\n", 2)       = 2 <0.000008>
     0.000042 write(1, "\n", 1)         = 1 <0.000007>
     3.033367 brk(0x2a08000)            = 0x2a08000 <0.000019>
     1.743621 brk(0x2a41000)            = 0x2a41000 <0.000019>
     2.166131 brk(0x2a86000)            = 0x2a86000 <0.000021>
     2.687461 brk(0x2aaf000)            = 0x2aaf000 <0.000017>
     0.266587 brk(0x2ae3000)            = 0x2ae3000 <0.000165>
     4.485236 brk(0x2b3a000)            = 0x2b3a000 <0.000129>
     1.482029 mmap(NULL, 344064, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa596451000 <0.000331>
     1.977664 mremap(0x7fa596451000, 344064, 389120, MREMAP_MAYMOVE) = 0x7fa5963f2000 <0.000284>
     0.781643 munmap(0x7fa5963f2000, 389120) = 0 <0.000252>
     0.053389 mmap(NULL, 1929216, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa5962ce000 <0.000183>

一次请求开销 20 秒,发现 brk 之间的耗时有个 14 秒,加上下面的 mmapmremap 开销 2.8 秒。但是在纯 Python 文件下执行只需要 1 秒以内,非常的纳闷。

在使用 Nuitka 是将 Python 文件转化为 so 文件,而不是全部打成一个 so 文件,因此采用了 py 文件替换来进行调试。整个路径都用 py 文件来运行了,当然依赖的一些类库使用的 so 的形式,并没有什么进展。

没办法只能使用 pdb 来进行一行一行的跟踪了。临时写了一个文件做为入口。

python -m pdb test.py

进入后,使用

n 执行这行命令
s 进入函数内部
l 查看上下文的代码

一步一步的执行下后,发现在

class CJsonEncoder(json.JSONEncoder):
    """
        to solve json.dumps datetime.datetime TypeError.
        TypeError: datetime.datetime(2014, 07, 12, 08, 56, 23) is not JSON serializable

        Use:
            json.dumps(data_obj, cls=CJsonEncoder)
    """
    def default(self, obj):
        if isinstance(obj, datetime.datetime):
            return obj.strftime('%Y-%m-%d %H:%M:%S')
        elif isinstance(obj, datetime.date):
            return obj.strftime('%Y-%m-%d')
        elif isinstance(obj, datetime.time):
            return obj.strftime('%H:%M:%S')
        else:
            return json.JSONEncoder.default(self, obj)

...

result = {
    'response':{
        'header':{
            'version':'1.0',
            'returnCode':self._code,
            'errorInfo':msg
            },
        'data':data
    }}
result_str = json.dumps(result, cls=CJsonEncoder)

CJsonEncoder 耗时 4 秒

一个令人惊讶的数值,对比了数据, 一个是 json.dumps(result, cls=CJsonEncoder) 一个是 json.dumps(result) ,耗时分别是 20 秒和 16 秒,光在这个自定义的json解析上居然花费 4 秒的时间。不可思议。

简直无可忍受,感觉这个 Nuitka 解决方案不行呀。

使用 simplejson 类库替换

刚好最近一直在做 json 相关类库的工作,之前也是测试过 Python 自带的 json 类库,性能也确实差,可能和我的 Python 版本有关系,还在使用 Python 2.6 的版本,吐血。

现有的 simplejson,后来 Python 将 simplejson 纳入标准类库了,但是由于 Python 分发出去,就无法更新标准类库了, 但是 simplejson 可以不断的独立更新,所以维护的更好一些,很多的很多的程序也都是用它。

看到 http://stackoverflow.com/a/17823905 上有说 simplejson 看是否有加速过,可以用这个

import simplejson
# If this is True, then c speedups are enabled.
print bool(getattr(simplejson, '_speedups', False))

如果返回 True ,那么就有使用特殊的加速过。所以性能更好一些。

具体替换实现

考虑到 simplejson 是符合 Python 的标准类库的接口,所以可以无缝兼容在使用。在使用了 simplejson 后,这个耗时回到了 1 秒的时间。

def patch_json():
    """
    using simplejson replace json
    """
    import json  # noqa
    import simplejson  # noqa
    sys.modules['json'] = sys.modules['simplejson']

在最开始的地方执行函数,替换掉标准的 json 的类库,让开发人员使用起来无感知,但是要注意做好兼容性测试。也要把这类隐形的替换在开发规范中声明好。

为什么使用了 Nuitka 变慢了

这个是我无法回答的了。因为 Nuitka 将 py 变成了 c++ 语言,再编译成 so 文件。按理不应该这么慢的。首先 strace 进入看,只有一些分配内存的情况系统调用。感觉这边在大量的一些 CPU 操作,不知道是不是 Nuitka 对这个优化不好,或者是老的 json 代码不行。

另外还发现,在 strace 中,一些查找 python 模块也还很耗时。

还有由于我的 Nuitka 解决方案是单个 py 直接变成单个 so,然后 py 和 so 混合使用的。不知道这边的切换会不会导致一些耗时的开销。

声明:未经允许禁止转载 东东东 陈煜东的博客 文章,谢谢。如经授权,转载请注明: 转载自东东东 陈煜东的博客

本文链接地址: Python 的 json 在 Nuitka 下性能好差 – https://www.chenyudong.com/archives/python-json-is-poor-performance-under-nuitka.html

分类: Python

Python Subprocess Popen 管道阻塞问题分析解决

使用Subprocess Popen的类库困挠了我一个月的问题终于解决了。

一句话就是:等待命令返回不要使用wait(),而是使用communicate(),但注意内存,大输出使用文件。

错误的使用例子

之前的代码这样使用的。

# 不合适的代码
def run_it(self, cmd):
    p = subprocess.Popen(cmd, stdout=subprocess.PIPE, shell=True,
                         stderr=subprocess.PIPE, close_fds=True)
    log.debug('running:%s' % cmd)
    p.wait()
    if p.returncode != 0:
        log.critical("Non zero exit code:%s executing: %s" % (p.returncode, cmd))
    return p.stdout

这段代码之前用着一直没有问题的,后来不知道为何就不能用了(后面知道了,原来输出内容增加,输出的问题本太长,把管道给堵塞了)。

这样的代码也在之前的一个项目中使用,而且调用的次数有上亿次,也没什么问题。之前倒是也卡住了一次,不过有个大神把问题找到了,因为Python版本低于2.7.6,Python对close_fds的一些实现不太好导致的,没有把管道释放掉,一直卡住。设置close_fds=True。不过这个并没有解决我的问题。

解决了我的问题

当时想着既然卡住了,那我就看看是输出了什么才卡住的,结果现有的代码无法支持我的想法,就换了代码,没想到就不卡住了。

def run_it(cmd):
    # _PIPE = subprocess.PIPE
    p = subprocess.Popen(cmd, stdout=subprocess.PIPE, shell=True,
                         stderr=subprocess.PIPE) #, close_fds=True)

    log.debug('running:%s' % cmd)
    out, err = p.communicate()
    log.debg(out)
    if p.returncode != 0:
        log.critical("Non zero exit code:%s executing: %s" % (p.returncode, cmd))
    return p.stdout

看看Python文档信息

Warning

Use communicate() rather than .stdin.write, .stdout.read or .stderr.read to avoid deadlocks due to any of the other OS pipe buffers filling up and blocking the child process.

Popen.wait()
    Wait for child process to terminate. Set and return returncode attribute.

    Warning This will deadlock when using stdout=PIPE and/or stderr=PIPE and the child process generates enough output to a pipe such that it blocks waiting for the OS pipe buffer to accept more data. Use communicate() to avoid that.
Popen.communicate(input=None)
    Interact with process: Send data to stdin. Read data from stdout and stderr, until end-of-file is reached. Wait for process to terminate. The optional input argument should be a string to be sent to the child process, or None, if no data should be sent to the child.

    communicate() returns a tuple (stdoutdata, stderrdata).

    Note that if you want to send data to the process’s stdin, you need to create the Popen object with stdin=PIPE. Similarly, to get anything other than None in the result tuple, you need to give stdout=PIPE and/or stderr=PIPE too.

    Note The data read is buffered in memory, so do not use this method if the data size is large or unlimited.

之前没注意,再细看一下文档,感觉豁然开朗。

Linux管道限制,为什么会阻塞呢?

下面来看看Can someone explain pipe buffer deadlock?的回答。

子进程产生一些数据,他们会被buffer起来,当buffer满了,会写到子进程的标准输出和标准错误输出,这些东西通过管道发送给父进程。当管道满了之后,子进程就停止写入,于是就卡住了。

及时取走管道的输出也没有问题

# 及时从管道中取走数据
def run_it(self, cmd):
    p = subprocess.Popen(cmd, stdout=subprocess.PIPE, shell=True,
                         stderr=subprocess.PIPE, close_fds=True)
    log.debug('running:%s' % cmd)
    for line in iter(p.stdout.readline, b''):
        print line,          # print to stdout immediately
    p.stdout.close()
    p.wait()
    if p.returncode != 0:
        log.critical("Non zero exit code:%s executing: %s" % (p.returncode, cmd))
    return p.stdout

看了Python的communicate()内部就是将stdout/stderr读取出来到一个list变量中的,最后函数结束时返回。

测试Linux管道阻塞问题

看到别人的例子,一直在想怎么测试输出64K的数据,发现dd这个思路很棒,是见过最优雅的例子了,精确控制输出的长度,其他都是从某些地方搞来大文件导入进来。

#!/usr/bin/env python
# coding: utf-8
# yc@2013/04/28

import subprocess

def test(size):
    print 'start'

    cmd = 'dd if=/dev/urandom bs=1 count=%d 2>/dev/null' % size
    p = subprocess.Popen(args=cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, close_fds=True)
    #p.communicate()
    p.wait()  # 这里超出管道限制,将会卡住子进程

    print 'end'

# 64KB
test(64 * 1024)

# 64KB + 1B
test(64 * 1024 + 1)

# output :
start
end
start   #  然后就阻塞了。

首先测试输出为 64KB 大小的情况。使用 dd 产生了正好 64KB 的标准输出,由 subprocess.Popen 调用,然后使用 wait() 等待 dd 调用结束。可以看到正确的 start 和 end 输出;然后测试比 64KB 多的情况,这种情况下只输出了 start,也就是说程序执行卡在了 p.wait() 上,程序死锁。

总结

那死锁问题如何避免呢?官方文档里推荐使用 Popen.communicate()。这个方法会把输出放在内存,而不是管道里,所以这时候上限就和内存大小有关了,一般不会有问题。而且如果要获得程序返回值,可以在调用 Popen.communicate() 之后取 Popen.returncode 的值。

但真的如果超过内存了,那么要考虑比如文件 stdout=open("process.out", "w") 的方式来解决了,不能使用管道了。

另外说一下。管道的要用清楚,不要随意的乱世用管道。比如没有input的时候,那么stdin就不要用管道了。

还有不要把简单的事情复杂化。比如echo 1 > /sys/linux/xxx修改文件,这么简单的功能就不要用Linux的shell调用了,使用Python自带的 open('file', 'w').write('1') 。尽量保持Python范。

参考

声明:未经允许禁止转载 东东东 陈煜东的博客 文章,谢谢。如经授权,转载请注明: 转载自东东东 陈煜东的博客

本文链接地址: Python Subprocess Popen 管道阻塞问题分析解决 – https://www.chenyudong.com/archives/python-subprocess-popen-block.html

分类: Python

« 较早的 文章 较新的 文章 »

Copyright © 2018 东东东 陈煜东的博客 粤ICP备13059639号-1

SITEMAP回到顶部 ↑