关于仿真速度瓶颈的挣扎！

pps453

小公司，一切都是自我摸索的！

1、刚开始是一台服务器，eda软件和项目目录都在一个这个服务器上，人少还凑合；
2、随着人数的提升，服务器负载逐渐变大，大家都和很卡；
3、想了一个办法，把project目录单独放在一个没有EDA的服务器上，然后通过NFS挂载到其他工作服务器，这样各个服务器互不影响，但是速度好像不太行；
所以，想讨论一下，这个仿真速度瓶颈应该在什么地方？
1、CPU 的频率，目前是Intel Xeon 6254 (18C,200W,3.1GHz) Processor *4；
2、也可能是内存，内存目前是512G，大多数情况下够用（swap是关闭的）；
3、硬盘的读写速度，固态硬盘，但是服务器的额固态速度应该也就比普通机械快个2-3倍吧，不像个人的能到7000M/S吧，没了解；
4、分布方式的问题，我的是存储连接只放项目project的服务器，其他服务器通过NFS挂载这台，也可能NFS是瓶颈；
5、网络环境，百兆、前兆、万兆的连接，服务器之间已用万兆光纤连接，但是效果似乎不明显；
  以上就是我的环境及考虑到的瓶颈点，望大佬们给指点一二，拜托各位了！感谢！

qbdscn

没有专门存储的情况下
1、使用nfsv3 ，对大量小文件比较友好
2、再分一个nfs服务器专门放PDK，
3、把仿真缓存路径改到服务器本机，放在nfs抗不住的

pps453

qbdscn 发表于 2025-4-11 10:37
没有专门存储的情况下
1、使用nfsv3 ，对大量小文件比较友好
2、再分一个nfs服务器专门放PDK，

目前有存储，但是存储必须挂在服务器下，这个服务器是不做工作的，其都是用NFS挂载到这台服务器，我总是感觉NFS传输速度太慢；仿真结果是放在本地的！

soway

给你一点儿提示l;
1. 如果瓶颈在存储，top查看，仿真任务会一会儿100%，一会儿不跑。

2. 如果仿真瓶颈在CPU，你top看，load值会超过你的真实物理core。（HT的core不算）

小环境，仿真的simulation目录你还是老是放本地硬盘上吧，如果是HDD，没有cache的raid卡，买块SSD很容易解决。过程数据也不用在乎数据保护。

CPU不足就买服务器，存储不足就改用本地SSD。

pps453

soway 发表于 2025-4-11 11:12
给你一点儿提示l;
1. 如果瓶颈在存储，top查看，仿真任务会一会儿100%，一会儿不跑。

感谢你的建议：

1、第一项你说的top是在哪查看？存储只负责存放项目文件，存储及连接存储的服务器是不参与仿真工作的；
2、平均load的上限应该是总线程数，有时能到100多，总线程数是144；
3、simulation目录是在工作服务器的，和project 是分开的，硬盘全部是固态！

soway

top就在你的计算服务器上看

这个load，top命令的右上角，或者uptime命令也会给出来。 如果你simulation过程目录都在本地ssd上，不会存在存储瓶颈了。

更可能是仿真的并行太多，CPU不足了。可以看看自己你最近跑了多少任务，是不是把CPU压完了。

pps453

soway 发表于 2025-4-11 12:56
top就在你的计算服务器上看

这个load，top命令的右上角，或者uptime命令也会给出来。 如果你simulation过 ...

其实我不太了解仿真的具体过程，按说一边是读project里的信息，一边是在本地写入，写入肯定是有瓶颈的，比如磁盘的写入速度，读也有，比如NFS协议以及交换机、光纤等的影响！

                               
登录/注册后可看大图

以这张突来看，平均负载50多，总线程144，所有还是有很大余量，内存却不太够了，但是还有40多G,这些能看到的参数还好说，传输、读写速度这类的不太好衡量！

soway

本地SSD就不会存在什么磁盘写入问题，你这才几个Job。

看core数量，而不是看HT后的线程数。你这2个hspice都用了 48个core了。6254，如果是4CPU，也就72core。 如果是2个CPU，才36core。 只要超过物理core，速度肯定会下降，毋庸置疑。 内存用光当然也会慢，但是更可能是直接OOM，被系统Kill掉。

talangerlai

我就是折腾服务器的，我可以负责的告诉你，你们的这台服务器不行。主要是CPU太差，Xeon 跑仿真是非常次的，赶紧换EPYC。我们项目组有5台服务器，全是我自己装的，其中两台的CPU是线程撕裂者 3995WX，64核心128线程，单路但单核频率高。后来有钱了陆续又添了两台双路 EPYC 7763，每颗64核心128线程。也就是说后面添的这两台双路服务器每台都有128物理核 256 线程。即便如此大的仿真跑起来还是不够的，几乎所有的仿真器都会建议你关掉超线程，这是因为开了超线程之后虽然逻辑核心数翻了一倍，但实际上是两个逻辑核心共享同一个FPU，而EDA仿真都是要占用FPU的。这就会导致你在高负载的情况下，某些分配了比如20个线程的仿真进程，其实它还是要等FPU轮换的，所以性能要低于关闭超线程，然后真正占据20个物理核心的仿真进程的速率。   

另外，也要看你用的什么仿真器，过去我们主要用的 Cadence 的Spectre 系列仿真器，要尽可能地利用上它最新版本的 Spectre X 仿真器，还需要仔细研究文档，确定最合理的线程分配数量，因为所有的仿真器的性能提升都不是跟线程占用数量的提升成正比的。比如我们的某路仿真，占据的线程数从32提升到64之后，总的仿真时间可能只缩短了20%-30%左右。所以为了整台服务器能更好的服务更多的工程师，你需要要求团队的成员在申请线程数量的时候保持克制。即便这些都做到了，有的时候更换另外一款仿真器，比如华大九天的 ALPS 仿真器，也能在大多数的情况下明显超过 Cadence Spectre X 仿真器的速度，这也是作为EDA管理员需要学习、了解和研究的。

最后这些都做到位了，性能还是不够，仿真时间还是太长。这就需要上GPU仿真了，现在支持GPU加速的仿真器是越来越多了。刚才提到的 Spectre X 和 ALPS 仿真器都能支持 GPU 加速。但这种加速一般来说用到的都是GPU的双精度浮点单元，一般的游戏卡不行，必须得 Nvidia的 A100/H100 这种。所以后来我们买了一台 8x A100 的GPU服务器，对于并行程度高，或者规模特别大的仿真，就交给GPU 服务器来处理了，有的时候能比纯CPU 仿真速度提高10-15倍。但GPU 加速仿真并非对所有的场景都能比CPU快，这就需要经验了。

最后说说你怀疑的 NFS 的问题，我们的NFS 就是 EDA 服务器承载的，普通的万兆网分享给所有的服务器。不论是Project 文件或者是 PDK，还是仿真临时文件都放在 NFS 上。一点儿问题也没有，不用担心，但前提是你得会配置，需要把NFS 配置成异步的模式，能利用内存做缓冲。你仔细观察可以发现，NFS Server 对CPU的占用微乎其微，主要还是取决于你 NFS 背后到底是什么盘构成的阵列。如果像我们一样是纯机械硬盘，那么如果缓冲设置的有问题，可能在应对大量的细小文件读写的时候会有点儿延迟。不过这点儿延迟绝不是你仿真速度变慢的理由，因为卡住仿真速度的永远是CPU。

对于CPU仿真来说，第一需要的是核心数要多，第二才是频率，一般服务器用的CPU 单核主频都不高，主打的是核心多。那么同样是72核心，如果你能用一块儿CPU来提供，就比分成两路CPU或者4路CPU要高效的多。因为这省去了不同的CPU之间协同工作的延时，差异会很明显，更不用说 Intel 的 Xeon 架构方面本来就比 AMD 的EPYC 要差好远。如果说CPU领域里什么样的CPU跑EDA的仿真的性能最高，那还是要看AMD EPYC 里带3D-vCache 的那些型号，跑仿真的速度要远强于同样代次 Zen 构架，同样核心数量但不带3D -vCache 的型号。不过，带3D-vCache 的型号CPU TDP 明显要高几十瓦，你服务器的散热必须要能跟得上才行。一般的正统的机架式服务器单纯给CPU提供散热，只要你装的是它的兼容性列表里提到的CPU，那就不会有散热问题。但如果你同时还要给这台服务器里装那种服务器专用的GPU，即自身没有散热扇，依赖服务器风道散热的专业显卡的话，那这台服务器的散热就未必能hold 住了。这就是为什么我们的那台专用的GPU服务器在CPU配置方面就很差，只配了两块儿 Intel 的 18核36线程的CPU的原因。

cyberwillis

好的，这是我的一点小建议。
在我看来，没有人应该通过网络共享文件夹 (NFS) 来访问同一个项目和文件，因为服务器会为每个连接的用户共享大量的资源，试图在每个用户会话中保存同一个文件的所有更改。最终可能会导致数据丢失。
在我看来，人们需要学习使用 Git 仓库，每次修改或完成某项工作后，都要将工作拉取并提交到 Git 服务器。这样，服务器几乎可以一直保持空闲，只需要负责用户会话的软件许可证，而每个用户的本地机器都必须每天下载整个项目，进行更改，然后在最后提交。只有最后一个提交的人需要处理某种合并情况来适应更改。
如果你已经这样做了，那可能是我的错，因为我在某个时候没有理解。如果你不能切换到这种模式，那么无论如何，随着项目文件的增长，你的团队对服务器的需求都会越来越大。