4

好的,我们已经走到了尽头,我非常感谢来自 SO 社区的反馈。

我们的基本问题是基于 MOSS 的 Intranet 性能缓慢——

一些环境信息:

我们有一个基于协作的站点的 MOSS 标准版本。

  • 站点数据库为 29 Gb
  • 我们有两个基于 VMWare 的前端服务器。(每个 2 个 32 位 CPU)
  • 不到 1000 个用户分布在所有时区
  • 我们有一个带有子网站的大型网站集。

一般症状: 加载首页和已“预热”的页面相当不错 - 但人迹罕至的页面/站点加载速度非常慢。

我们看到峰值,一个页面突然需要 30 秒才能加载,而更正常的 2

这是我们已经完成的工作:

  • 在爬行时按比例缩小
  • 启用对象和 blob 缓存
  • 优化的 VMware 设置
  • 遵循关于 MOSS 共享点最佳实践的 Microsoft IT 白皮书(尤其是列表大小等)

我不知道这里还能做什么 - 拆分为多个网站集?

切换到 64 位前端服务器?

很高兴听到其他处于类似情况的人的来信。

4

9 回答 9

3

你没有说你的前端服务器有多少内存——考虑到它们是 32 位的,我假设每个工作进程的最大值约为 2gb + 变化。

我的建议?切换到 64 位,添加更多内存,并检查每个前端是否只使用一个 w3wp 工作进程。深入了解“网络花园”,也就是说,您在每个前端配置多个 w3wp 进程的位置。首先,从每个前端的两个工作进程开始,看看效果如何。还要确保它们被设置为回收,并且每对工作进程的回收不重叠 - 拥有两个以上的工作人员意味着他们可以轮流回收而不切断访问权限。

只是我的 0.02。

-Oisin

于 2008-11-18T14:44:58.320 回答
2

我认为您的首要任务是确定问题实际出在哪里 - 直到您知道您正在浪费时间更改事物。

  • 数据库服务器是在单独的服务器上还是在您的 Web 服务器上?

  • 您是否在前端或数据库服务器上看到 CPU/磁盘瓶颈?

  • 这听起来像你的世界。您是否从靠近服务器的网络中看到相同的性能问题 - 是 WAN 问题吗?

于 2008-11-18T16:03:18.100 回答
2

感谢大家提供一些有用的建议,我刚刚学到的一件事是我们的对象缓存基本上没有做任何事情!这是因为它的工作方式似乎是,如果您有权在网站集的任何位置进行编辑,则默认情况下会禁用跨门户的对象缓存。由于所有用户都至少拥有某些权限,这意味着缓存基本上什么都不做!

我们通过启用缓存调试发现了这一点,它在 html 中添加了一个关于正在使用的缓存的小注释。在经过身份验证的缓存配置文件中更改设置“允许作者查看缓存的内容”后,

我们正在看到这对编辑有什么影响,但对于普通观众来说,轶事证据表明它正在产生巨大的影响!

于 2008-11-18T16:36:24.850 回答
2

是的,缓存是减少系统负载的最佳方式。向 SQL 服务器添加 RAM 也很好。(对于您的 SQL 服务器来说,64 位确实是必须的,WFE 并不那么重要)。

不确定您是否要回收这些流程。我没有证据证明这一点,除了与某人的谈话说回收过程看起来已经解决了一个性能问题,但正在介绍其他问题。

我提到缓存了吗?

SQL 服务器应处理高达 100Gb 的数据库,但在这种大小下,它们将难以管理以进行备份等,因此您现在可能需要计划将您的站点拆分为相关的站点集合,但这可能不相关性能。

于 2008-11-19T21:57:26.260 回答
1

您是否看过规划软件边界 (Office SharePoint Server)

乍一看,您的服务器符合他们推荐的设置。

为了提高性能,您应该看看:

  • 64 位服务器
  • 限制文档列表中显示的项目数量 (来源:microsoft.com限制显示的项目数量
于 2008-11-18T15:50:33.663 回答
0

一定要检查磁盘使用情况。如果您有两个虚拟机并且它们运行相同的磁盘/SAN,请确保它不太忙。过载的 SAN 会降低性能

于 2008-11-20T01:50:49.863 回答
0

我会把我的帽子扔进戒指并推荐64位。也许不是立即修复,但展望未来,我会将迁移到 64 位作为您整个农场的目标。

我也会对 Nat 的评论提出一些问题,即在 Web 前端并不重要。我不会争论基准或争论内存可寻址性。它真的比这更简单。

Microsoft 已公开表示 2007 是最后一个将在 32 位服务器上运行的 SharePoint 版本。向前发展 64 位将成为一项要求 - 所以就像 FRAM 机油滤清器的人所说 - “现在付钱给我,或者以后付钱给我”......

于 2009-01-20T04:21:50.510 回答
0

我们也有性能问题。我们在 win 2008 64bit 女巫上升级了一些差异,但没有预期的那么多。

bih 的提升让我们从 NTLM 认证更改为 Kerberos。这是我们的重大改进。

希望这对某人有帮助

于 2009-06-30T12:22:11.733 回答
0

我运行了一个非常相似的设置,但是我们有超过 400GB 的空间分布在 3 个网站集上。在进入 64 位路径之前,您还可以尝试其他一些事情。

  • 确保数据库服务器和 Web 前端之间没有磁盘或带宽问题。数据库服务器的网络速度至关重要。
  • 检查数据库服务器本身,如果磁盘在 SAN 上,如果 SAN 上的物理驱动器存在争用,则可能会出现性能问题。RAM 也很重要,它可以缓存到内存的越多,等待磁盘响应的时间就越少。
  • 安排爬网作业在正常工作时间之外运行
  • 您已经启用了对象缓存,这可能会有很大帮助,请确保也启用了压缩!对于较低带宽的用户,sharepoint 会向用户发送大量 CSS 信息,如果启用压缩,这些信息会压缩到其大小的 1/10。
  • 这是另一个大问题,确保您公司的 DNS 在其他位置正常工作,并检查此问题是否与外部来源有关。IE 我们有一个 sonicwall 防火墙,它对通过它连接的办公室的响应时间非常苛刻。
  • Micrsoft 有一份关于性能计数器监控的白皮书。它非常彻底,将帮助您缩小 CPU/RAM/网络/HD IO 之间的问题。

希望这可以帮助!

于 2011-03-09T19:47:53.880 回答