服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

针对低延迟10GbE – > 1GbEnetworking的TCP拥塞控制?

我有一个10GbE连接到交换机的服务器,和10个客户端,每个连接1GbE连接到同一个交换机。 在每个客户机上并行运行nuttcp,我可以以接近线速的速度同时向服务器推送10个TCP数据stream(即,同时从所有10个客户机以每秒100兆字节为单位)。 然而,当我逆转方向并将数据从服务器发送到客户端时(即,10个TCPstream,每个客户端一个TCP连接),TCP重新传输量猛增,性能下降到30,20甚至10兆字节每秒每个客户端。 我希望得到这些数字,因为这种stream量模式是我关心的某些应用程序的代表。 我已经validation了我的服务器能够通过在类似的服务器上通过10GbE连接执行相同的实验来饱和10GbE链路。 我已经validation在我的任何端口上都没有错误。 最后,当我强行钳制(限制)接收器的TCP窗口大小时,我可以获得更高的带宽(30-40兆字节/秒)。 如果我将其限制得非常低,我可以将重传数据设置为零(带宽低得可怜)。 因此,我相当有把握地确信我的交换机中的缓冲区溢出,导致拥塞导致的数据包丢失。 但是,我认为TCP的拥塞控制本来是要处理好的,最终稳定在线速度的50%以上。 所以我的第一个问题很简单:哪个TCP拥塞控制algorithm最适合我的情况? 有很多可用的,但他们似乎主要是针对有损networking或高带宽高延迟networking或无线networking…没有一个适用于我的情况。 第二个问题:还有什么我可以尝试?

如何在Linux内核中禁用perf子系统?

我正在运行一些基准。 我的基准跑步者监视实验之间的dmesg缓冲区,寻找任何可能影响性能的东西。 今天它扔了这个: [2015-08-17 10:20:14警告] dmesg似乎已经改变了! 差异如下: — 2015-08-17 09:55:00 +++ 2015-08-17 10:20:14 @@ -825,3 +825,4 @@ [3.802206] [drm]启用RC6状态:RC6开启,RC6pclosures,RC6ppclosures [7.900533] r8169 0000:06:00.0 eth0:连结 [7.900541] IPv6:ADDRCONF(NETDEV_CHANGE):eth0:链接已准备就绪 perf [236832.221937] perf中断时间过长(2504> 2500),将kernel.perf_event_max_sample_rate降至50000 经过一番search之后,我现在知道这涉及到linux内核中称为“perf”的剖析子系统。 我不认为我们需要这个,所以我想完全禁用它。 再次search,我发现sysctl perf_cpu_time_max_percent可以帮助。 这里有人build议通过将其设置为0来禁用它。在这里阅读更多: perf_cpu_time_max_percent: 向内核提示应该允许使用多lessCPU时间来处理perf采样事件。 如果perf子系统被告知其样本超过此限制,则会降低其采样频率以尝试降低其CPU使用率。 一些perf抽样发生在NMI中。 如果这些样本意外花费太长的时间执行,那么NMI可能会彼此紧挨在一起,以至于没有其他的东西可以执行。 0:禁用该机制。 不pipeCPU占用多less时间,都不要监视或纠正每个采样率。 1-100:尝试将perf的采样率调整到这个百分比的CPU。 注意:内核计算每个样本事件的“预期”长度。 这里的100意味着100%的预期长度。 即使设置为100,如果超过此长度,仍可能会看到样品限制。 设置为0,如果你真的不在乎多lessCPU消耗。 这对我来说听起来像0意味着分析采样率不再检查,但freq子系统保持运行(?)。 任何人都可以阐明如何彻底禁用与freq内核分析? 编辑:有人build议我尝试build立一个没有perf的内核,但我不认为这是可能的。 该选项似乎不可切换: 编辑2:更多的阅读后,我决定我可以设置kernel.perf_event_max_sample_rate为零。 即每秒没有采样。 但是,你不能这样做( 来源 ): […]

组策略:映射的驱动器无法加载,Windows Server 2012 Active Directory和Windows Pro 10

networking: 多网站域名。 每个站点有2个本地(现场,相同的子网)Windows Server 2012 R2域控制器。 在Windows站点和服务中正确定义站点。 每个站点的DNSlogging只有定义了两个本地DNS服务器。 所有的客户端都是Windows 10 Pro 64位的所有更新。 这两个networking都使用经过authentication的CAT6电缆在Cisco交换机上完全千兆位运行。 每个站点都有一个本地(现场,同一子网)的Synology存储服务器。 作为组策略的一部分,两个networking驱动器被映射到Synology服务器上的共享。 连接性诊断: dcdiag /test:dns /v /c /e报告所有服务器和所有testing的PASS echo %logonserver% 总是返回一个本地DC nltest /dsgetdc 总是显示本地DC和正确的本地IP 在A站点,两个networking驱动器都显示出来,可能有0.5%的机会出现故障(我经历了一些驱动器显示不正确的启动)。 问题: 在B站点,networking驱动器可能无法显示30%的时间。 有时它是两个驱动器,有时是一个或另一个。 问题大多是随机的,似乎并不遵循任何特定的用户或工作站。 症状: 在问题出现的30%的时间里: 5%的时间gpupdate或gpupdate /force将解决问题,驱动器将立即出现。 如果gpupdate在第一次尝试时不起作用,那么之后几乎不会起作用(对于该引导) 5%的时间gpupdate或gpupdate /force将导致只有一个驱动器出现 20%的时间, gpupdate不会解决这个问题,但下一次启动将罚款 50%的时间, gpupdate不会解决这个问题,但一次启动和另一个 gpupdate ,驱动器将出现 20%的时间,它会需要多次重新启动(和每个启动gpupdate ),驱动器出现之前。 有时候是2次启动,但是在硬盘出现之前,我不得不重启计算机,有时甚至要重启6次或7次。 在过去的20%的时间里,我有时会从gpupdate过程中得到错误。 The processing of Group Policy failed. […]