Ubuntu中文论坛

准备搭建本地yum仓库做实验,
第一想到的就是把阿里云的repo源全部弄下来,不知道多大,就先拿腾讯云服务器当实验yum.遇到几个问题

环境: 1核1G内存 带宽1M 系统:centos 6.9

第一次试探的尝试脚本一个一个下载,因为不知道多大,发现一共6706个包,用时约31分钟 大小5.6G
--------------------------------------
sum=6706

real 30m57.105s
user 0m11.973s
sys 0m36.484s

[root@bbs packet2]# du -sh
5.6G

第二次下载50次并发 用时15分30秒左右
--------------------------------------
sum=6706

real 15m29.854s
user 0m17.168s
sys 0m36.886s
[root@bbs packet2]#

第三次100次并发 用时14分3秒左右
--------------------------------------
sum=6706

real 14m2.561s
user 0m15.493s
sys 0m31.249s

rpm安装包 大多集中在20k左右
[root@bbs packet2]# ls -sh|awk '{print $1}'|sort|uniq -c|sort -nr|head -10
321 20K
319 16K
293 24K
252 28K
240 12K
216 32K
173 40K
168 36K
137 8.0K
128 44K
[root@bbs packet2]#

结果挺让人激动的
但是发现 我明明只有1M带宽 以第三次结果来计算 大小5.6G=5.6 * 1024M=5734.4M 用时14分3秒=14*60+3=843s 速率:5734.4M / 843s =6.8M/s 6.8M/s??? 真正的速率是6.8/8 0.85 还是6.8*8 54.4?

问题
1.下载网速和带宽是什么关系?
2.我看100次并发下载时,cpu占用和内存也很低,到底可以后台并发多少?影响瓶颈是什?么网络带宽还是IO?好像内存和cpu并没什么影响啊

1. 下载速率 < 带宽
2. 网络带宽

给你的带宽应该是100M吧？或者是限速逻辑有问题？

内存和cpu有影响但是影响不大。按照现在的cpu处理能力，把一个核沾满所需要的吞吐是在GB级别的（E5-2667 v3 @ 3.20 GHz）
再考虑到带宽和磁盘的限制，实际肯定达不到这么多，所以cpu和内存的影响基本可以忽略

lilydjwg 写了：1. 下载速率 < 带宽
2. 网络带宽

给你的带宽应该是100M吧？或者是限速逻辑有问题？

理论上是下载速度<带宽 但是我不知道我算的对不对

云服务器上最低配置 带宽就是1m 至少他们是这么写的
机器配置
操作系统 CentOS 6.8 64位
CPU 1核
内存 1GB
系统盘 50 GB（本地硬盘）
公网带宽 1Mbps

真是奇怪

qgymib 写了：内存和cpu有影响但是影响不大。按照现在的cpu处理能力，把一个核沾满所需要的吞吐是在GB级别的（E5-2667 v3 @ 3.20 GHz）
再考虑到带宽和磁盘的限制，实际肯定达不到这么多，所以cpu和内存的影响基本可以忽略

是的 我分别使用阿里云和腾讯运 和笔记本虚拟机分别下载实验 cpu和内存基本很低很低.
值得说明的是 虚拟机不算宿主系统,开5个虚拟机.用其中一个虚拟机(1cpu1核心1g内存)也跑一样的并发,cpu和内存也使用不多.很感人.就是笔记本温度很高.

我在想阻碍并发的瓶颈和硬盘io 和网卡\网络带宽.和系统ulimit等参数. cpu和内存真的没压力

我弄不清楚 移动cpu和台式cpu和服务器常用cpu 怎么比较 怎么测试
还有就是这神奇带宽和下载的关系 怎么算都超出云服务器外网带宽

还有个可能：你的下载有问题。你并不是计算的实际下载数据量，而是假设它们是一样的。有可能你的并发下载逻辑有问题，有可能因为并发导致服务器报错，结果下载的数据量远少于预期。

对了，有个工具可以很方便地看实时使用带宽（以及其它数据，比如磁盘I/O使用）： dstat。

为什么都不去读一下文档呢？
根据腾讯云的官方文档 https://cloud.tencent.com/document/product/213/12523
它所标称的公网带宽，实际是出网方向的带宽，而实际分配的入网方向带宽至少有10M。所以这个数据并没有什么奇怪的

astolia 写了：为什么都不去读一下文档呢？
根据腾讯云的官方文档 https://cloud.tencent.com/document/product/213/12523
它所标称的公网带宽，实际是出网方向的带宽，而实际分配的入网方向带宽至少有10M。所以这个数据并没有什么奇怪的

因为我不是腾讯云的用户，也不是他们的客服。我也没想到专业领域的东西标称也是如此不严谨（或者是提问者提供信息不全？）。也被我说中了，是限速逻辑的事情。

有可能小包过多导致限速可能没跟上-。-
我用腾讯云1M带宽下大文件到是定死了100多k，坑

astolia 写了：为什么都不去读一下文档呢？
根据腾讯云的官方文档 https://cloud.tencent.com/document/product/213/12523
它所标称的公网带宽，实际是出网方向的带宽，而实际分配的入网方向带宽至少有10M。所以这个数据并没有什么奇怪的

原来如此 白激动了 那怎么能充分利用带宽?有思路没