问题场景:高频系统中,agent 会向ATS 服务器发出刷新和预缓存的请求,这里的请求head 里面有GET ,PURGE等,因为一般的预缓存都是小文件,但是某天,突然服务器oom。。。罪魁祸首发现是并发GET 大文件将服务器打死了。第一个版本是python 的,第二个版本是golang 实现的, 这里记录下两种语言的 下载大文件的实现方式。
第一种是python,使用的是request 库, 使用流式读取的方式,写到空设备中去。
res = self.session.request(method, url, data=body, headers=header, timeout=timeout, proxies=proxies, stream=True) with open("/dev/null", 'wb') as f: for chunk in res.iter_content(chunk_size=1024): if chunk: # filter out keep-alive new chunks f.write(chunk) f.flush()
第二种方式,对于golang ,使用io.Copy(), 将response copy 到空设备中。
func downLoadFile(url string)(len int, err error){ //err write /dev/null: bad file descriptor# out, err := os.OpenFile("/dev/null", os.O_RDWR|os.O_CREATE|os.O_APPEND, 0666) defer out.Close() resp, err := http.Get(url) defer resp.Body.Close() n, err := io.Copy(out, resp.Body) return n, err }
使用这种方式为什么不会出现oom 的情况?因为两个原因,第一个, resp.Body 只是个reader 并没有发生真实的读取操作,第二个是io.copy 这个函数设置了缓冲区大小限制为3m,不会一次全部读取到内存中,下面是标准库的源码:
func Copy(dst Writer, src Reader) (written int64, err error) { return copyBuffer(dst, src, nil) } // copyBuffer is the actual implementation of Copy and CopyBuffer. // if buf is nil, one is allocated. func copyBuffer(dst Writer, src Reader, buf []byte) (written int64, err error) { // If the reader has a WriteTo method, use it to do the copy. // Avoids an allocation and a copy. if wt, ok := src.(WriterTo); ok { return wt.WriteTo(dst) } // Similarly, if the writer has a ReadFrom method, use it to do the copy. if rt, ok := dst.(ReaderFrom); ok { return rt.ReadFrom(src) } if buf == nil { buf = make([]byte, 32*1024) //这一步可以控制每次缓冲区迭代的大小,默认大小是3m } for { nr, er := src.Read(buf) if nr > 0 { nw, ew := dst.Write(buf[0:nr]) if nw > 0 { written += int64(nw) } if ew != nil { err = ew break } if nr != nw { err = ErrShortWrite break } } if er != nil { if er != EOF { err = er } break } } return written, err }