构建服务器硬件配置
所以我已经看到这个问题，但我正在寻找更多一般建议：如何指定构建服务器？具体来说，我应该采取哪些步骤来准确决定新构建服务器使用什么处理器、HD、RAM 等。 我应该考虑哪些因素来决定是否使用虚拟化？
我正在寻找需要采取的一般步骤来决定购买哪些硬件。 引导我得出具体结论的步骤 - 认为“我需要 4 GB 内存”而不是“你能买得起的尽可能多的内存”
PS 我故意不提供具体细节，因为我正在寻找教人 - to-fish 答案，不是仅适用于我的情况的答案。
So I've seen this question, but I'm looking for some more general advice: How do you spec out a build server? Specifically what steps should I take to decide exactly what processor, HD, RAM, etc. to use for a new build server. What factors should I consider to decide whether to use virtualization?
I'm looking for general steps I need to take to come to the decision of what hardware to buy. Steps that lead me to specific conclusions - think "I will need 4 gigs of ram" instead of "As much RAM as you can afford"
P.S. I'm deliberately not giving specifics because I'm looking for the teach-a-man-to-fish answer, not an answer that will only apply to my situation.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
答案是机器需要什么要求才能“构建”您的代码。 这完全取决于您正在谈论的代码。
如果它有几千行代码，那么只需将旧桌面从柜子里拿出来即可。 如果它有几十亿行代码，那么请与银行经理联系，为您提供刀片机箱的贷款！
我认为开始构建服务器的最佳位置是为自己购买一台新的开发机器，然后重建旧机器作为构建服务器。
The answer is what requirements will the machine need in order to "build" your code. That is entirely dependent on the code you're talking about.
If its a few thousand lines of code then just pull that old desktop out of the closet. If its a few billion lines of code then speak to the bank manager about giving you a loan for a blade enclosure!
I think the best place to start with a build server though is buy yourself a new developer machine and then rebuild your old one to be your build server.
我首先会收集一些关于您当前用于构建的任何系统上的构建的性能指标。 我会特别关注 CPU 和内存利用率、从磁盘读取和写入的数据量以及生成的网络流量（如果有）。 在 Windows 上，您可以使用 perfmon 来获取所有这些数据； 在 Linux 上，您可以使用 vmstat、iostat 和 top 等工具。 找出瓶颈在哪里——您的构建是否受 CPU 限制？ 磁盘绑定？ 缺乏内存？ 这些问题的答案将指导您的购买决定——如果您的构建对 CPU 造成了很大的影响，但生成的数据相对较少，那么放入基于 SCSI 的 RAID 磁盘就是浪费金钱。
在收集这些指标时，您可能希望尝试以不同的并行级别运行构建。 如果您使用的是 gnumake，请使用
-j 2、-j 4和-j 8运行构建。 这将帮助您了解构建是否受 CPU 或磁盘限制。还要考虑这样一种可能性，即满足您需求的正确构建服务器实际上可能是一组廉价系统，而不是一个巨大的盒子——有很多分布式构建系统（gmake/distcc、pvmgmake、ElectricAccelerator 等）可以帮助您比单个大型系统更好地利用一系列廉价计算机。
I would start by collecting some performance metrics on the build on whatever system you currently use to build. I would specifically look at CPU and memory utilization, the amount of data read and written from disk, and the amount of network traffic (if any) generated. On Windows you can use perfmon to get all of this data; on Linux, you can use tools like vmstat, iostat and top. Figure out where the bottlenecks are -- is your build CPU bound? Disk bound? Starved for RAM? The answers to these questions will guide your purchase decision -- if your build hammers the CPU but generates relatively little data, putting in a screaming SCSI-based RAID disk is a waste of money.
You may want to try running your build with varying levels of parallelism as you collect these metrics as well. If you're using gnumake, run your build with
-j 2,-j 4and-j 8. This will help you see if the build is CPU or disk limited.Also consider the possibility that the right build server for your needs might actually be a cluster of cheap systems rather than a single massive box -- there are lots of distributed build systems out there (gmake/distcc, pvmgmake, ElectricAccelerator, etc) that can help you leverage an array of cheap computers better than you could a single big system.
需要考虑的事项：
预计将同时建设多少个项目？ 一个项目等待另一个项目完成是否可以接受？
您打算进行 CI 或计划构建吗？
您的构建通常需要多长时间？
您使用什么构建软件？
大多数 Web 项目都足够小（构建时间不到 5 分钟），因此购买大型服务器没有意义。
举个例子，
我们有大约 20 名开发人员积极致力于 6 个不同的项目。 我们为所有项目使用运行 CI 的单个 TFS 构建服务器。 它们将在每次签入时进行构建。
我们所有的项目都在 3 分钟内构建完成。
构建服务器是一个带有 4GB 内存的四核服务器。 我们使用它的主要原因是用于 QA 的性能开发和分段构建。 构建完成后，该应用程序将自动部署到适当的服务器。 它还负责针对这些项目运行单元和 Web 测试。
您使用的构建软件类型非常重要。 TFS 可以利用每个核心在解决方案中并行构建项目。 如果您的构建软件无法做到这一点，那么您可以根据您的需要研究拥有多个构建服务器。
Things to consider:
How many projects are going to be expected to build simultaneously? Is it acceptable for one project to wait while another finishes?
Are you going to do CI or scheduled builds?
How long do your builds normally take?
What build software are you using?
Most web projects are small enough (build times under 5 minutes) that buying a large server just doesn't make sense.
As an example,
We have about 20 devs actively working on 6 different projects. We are using a single TFS Build server running CI for all of the projects. They are set to build on every check in.
All of our projects build in under 3 minutes.
The build server is a single quad core with 4GB of ram. The primary reason we use it is to performance dev and staging builds for QA. Once a build completes, that application is auto deployed to the appropriate server(s). It is also responsible for running unit and web tests against those projects.
The type of build software you use is very important. TFS can take advantage of each core to parallel build projects within a solution. If your build software can't do that, then you might investigate having multiple build servers depending on your needs.
我们的商店支持 16 种产品，范围从几千行代码到数十万行（目前可能超过一百万行）。 我们使用 3 台 HP 服务器（大约 5 年历史），双四核，10GB RAM。 这些磁盘是 7200 RPM SCSI 驱动器。 所有内容均通过命令行上的 msbuild 进行编译，并启用并行编译。
通过这种设置，到目前为止我们最大的瓶颈是磁盘 I/O。 我们将完全擦除我们的源代码并在每个构建上重新签出，并且删除和签出时间非常慢。 编译和发布时间也很慢。 CPU 和 RAM 不会远程征税。
我正在更新这些服务器，因此我将走工作站级机器的路线，使用 4 台而不是 3 台，并用我能买得起的最好/最快的 SSD 替换 SCSI 驱动器。 如果您有与此类似的设置，则应考虑磁盘 I/O。
Our shop supports 16 products that range from a few thousands of lines of code to hundreds of thousands of lines (maybe a million+ at this point). We use 3 HP servers (about 5 years old), dual quad core with 10GB of RAM. The disks are 7200 RPM SCSI drives. All compiled via msbuild on the command line with the parallel compilations enabled.
With that setup, our biggest bottleneck by far is the disk I/O. We will completely wipe our source code and re-checkout on every build, and the delete and checkout times are really slow. The compilation and publishing times are slow as well. The CPU and RAM are not remotely taxed.
I am in the process of refreshing these servers, so I am going the route of workstation class machines, go with 4 instead of 3, and replacing the SCSI drives with the best/fastest SSDs I can afford. If you have a setup similar to this, then disk I/O should be a consideration.