Docker容器HTTP请求限制

我是Docker的新手,所以很可能我缺少一些东西。

我正在使用Elasticsearch使用此图像运行容器。

我能够正确设置所有内容。之后,我使用的是一个由同事开发的脚本,用于插入一些数据,基本上是查询MySQL数据库并发出HTTP请求" title="HTTP请求">HTTP请求。

问题是,这些请求中的许多请求都会卡住,直到失败。如果netstat -tn | grep 9200我知道了:

tcp6       0      0 ::1:58436               ::1:9200                TIME_WAIT  

tcp6 0 0 ::1:59274 ::1:9200 TIME_WAIT

...

tcp6 0 0 ::1:58436 ::1:9200 TIME_WAIT

tcp6 0 0 ::1:59274 ::1:9200 TIME_WAIT

有很多要求。在这一点上,我不确定这是否与elasticsearch或泊坞窗有关。如果在我的计算机上安装了Elasticsearch,则不会发生这种情况。

一些信息:

$ docker version

Client version: 1.6.2

Client API version: 1.18

Go version (client): go1.4.2

Git commit (client): 7c8fca2

OS/Arch (client): linux/amd64

Server version: 1.6.2

Server API version: 1.18

Go version (server): go1.4.2

Git commit (server): 7c8fca2

OS/Arch (server): linux/amd64

$ docker info

Containers: 6

Images: 103

Storage Driver: devicemapper

Pool Name: docker-252:1-9188072-pool

Pool Blocksize: 65.54 kB

Backing Filesystem: extfs

Data file: /dev/loop0

Metadata file: /dev/loop1

Data Space Used: 4.255 GB

Data Space Total: 107.4 GB

Data Space Available: 103.1 GB

Metadata Space Used: 6.758 MB

Metadata Space Total: 2.147 GB

Metadata Space Available: 2.141 GB

Udev Sync Supported: false

Data loop file: /var/lib/docker/devicemapper/devicemapper/data

Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata

Library Version: 1.02.82-git (2013-10-04)

Execution Driver: native-0.2

Kernel Version: 3.14.22-031422-generic

Operating System: Ubuntu 14.04.2 LTS

CPUs: 4

Total Memory: 15.37 GiB

$ docker logs elasticsearch

[2015-06-15 09:10:33,761][INFO ][node ] [Energizer] version[1.6.0], pid[1], build[cdd3ac4/2015-06-09T13:36:34Z]

[2015-06-15 09:10:33,762][INFO ][node ] [Energizer] initializing ...

[2015-06-15 09:10:33,766][INFO ][plugins ] [Energizer] loaded [], sites []

[2015-06-15 09:10:33,792][INFO ][env ] [Energizer] using [1] data paths, mounts [[/usr/share/elasticsearch/data (/dev/mapper/ubuntu--vg-root)]], net usable_space [145.3gb], net total_space [204.3gb], types [ext4]

[2015-06-15 09:10:35,516][INFO ][node ] [Energizer] initialized

[2015-06-15 09:10:35,516][INFO ][node ] [Energizer] starting ...

[2015-06-15 09:10:35,642][INFO ][transport ] [Energizer] bound_address {inet[/0:0:0:0:0:0:0:0:9300]}, publish_address {inet[/172.17.0.5:9300]}

[2015-06-15 09:10:35,657][INFO ][discovery ] [Energizer] elasticsearch/Y1zfiri4QO21zRhcI-bTXA

[2015-06-15 09:10:39,426][INFO ][cluster.service ] [Energizer] new_master [Energizer][Y1zfiri4QO21zRhcI-bTXA][76dea3e6d424][inet[/172.17.0.5:9300]], reason: zen-disco-join (elected_as_master)

[2015-06-15 09:10:39,446][INFO ][http ] [Energizer] bound_address {inet[/0:0:0:0:0:0:0:0:9200]}, publish_address {inet[/172.17.0.5:9200]}

[2015-06-15 09:10:39,446][INFO ][node ] [Energizer] started

[2015-06-15 09:10:39,479][INFO ][gateway ] [Energizer] recovered [0] indices into cluster_state

脚本的重要部分:

for package in c.fetchall():

id_package, tracking_number, order_number, payment_info, shipment_provider_name, package_status_name=package

el['tracking_number'] = tracking_number

el['order_number'] = order_number

el['payment_info'] = payment_info

el['shipment_provider_name'] = shipment_provider_name

el['package_status_name'] = package_status_name

requests.put("http://localhost:9200/packages/package/%s/_create"%(id_package), json=el)

回答:

因此,Docker或Elastic都不是问题。回顾一下,在本地通过Elasticsearch设置抛出PUT请求的相同脚本可以正常工作,但是在使用数千个文档(20k)后,使用Elasticsearch抛出容器时失败。请注意,文件总数大约为80万。

那么,发生了什么事?当您设置在本地主机上运行的somethig并向其发出请求(在本例中为PUT请求)时,该请求将通过回送接口。实际上,这意味着不会建立任何TCP连接,从而使速度大大提高。

设置Docker容器时,端口已绑定到主机。尽管脚本仍在所需端口上向localhost发出请求,但仍通过docker0接口在主机和Docker容器之间创建了TCP连接。这是以两件事为代价的:

  • 建立TCP连接的时间
  • TIME_WAIT状态

这实际上是一个更现实的情况。我们在另一台机器上安装了Elasticsearch,并进行了完全相同的测试,并得到了预期的相同结果。

问题在于我们正在发送请求,并为每个请求创建一个新的连接。由于TCP的工作方式,无法立即关闭连接。这意味着我们将使用所有可用的连接,直到没有连接可用为止,因为创建速率高于实际的关闭速率。

解决此问题的三个建议:

  1. 偶尔暂停一次请求。也许每X个请求都会hibernate,以使TIME_WAIT通过并关闭连接
  2. 发送Connection: close标头:选项,以使发送方在响应完成后发出将关闭连接的信号。
  3. 重用连接。

我最终选择了选项3),并重写了我的同事的脚本并重新使用了相同的TCP连接。

以上是 Docker容器HTTP请求限制 的全部内容, 来源链接: utcz.com/qa/432766.html

回到顶部