@ShreyaR 目标是动态调整窗口大小，使得每个窗口大小都易于管理，而不受窗口数量的影响吗？如果是后者(我猜是这样),有没有更明确的想法，什么被认为是不那么激进/更好的？我假设这与集群容量有关，需要根据那个进行调整。
为了更好地理解这个问题，我有几个问题：

• 我们最初选择除以40的原因是什么，这是硬编码的吗？如果不是，我们是否会自动配置窗口大小？
• 你能将我指向设置窗口大小的代码块吗？
• 验证新窗口大小计算创建的窗口被认为是不那么激进的最佳方法是什么？

好问题！
我们目前遇到的问题是，在当前窗口大小下，我们不应该经历当前的内存压力。因此，解决这个问题的目标是了解内存压力来自哪里，以及我们在设置窗口时是否可以采取措施来减少它。
内存压力表现为完整的对象存储和随后的对象溢出到磁盘。根据与ray团队的讨论，鉴于当前窗口大小为<total object store memory (tosm)> / 40,我们不应该观察到任何磁盘溢出。更激进的窗口大小将是<tosm> / <num_trials * 2.5>。

• 我们除以40,因为对于单个试验，建议的窗口大小为<tosm> / 5。由于我们对hyperopt运行8个试验，每个试验都独立地进行数据加载和 Shuffle ，我们将当前窗口大小设置为<tosm> / (5 * 8)。这今天在Ludwig中没有硬编码，预计用户会提供。
• 如果我们将窗口大小设置得更大，如<tosm> / <num_trials * 2.5>,并且看不到任何对象溢出，那么这将验证较少激进的窗口设置是有效的。

AnyScale团队的建议：尝试使用基于推送的 Shuffle 。