配置SQL Server去使用 Windows的 Large-Page/Huge-Page allocations

今天,一个可改变控制的实现激使我去写这篇文章,这个可改变的控制就是允许运行在Windows200864位服务器上的SQL Server 2005企业版上

使用跟踪标志834,SQLSERVER会利用 Large-Page allocations去构建内存中的Buffer Pool。

下面是我对 Large-Page allocations的理解和这个Large-Page allocations对性能的提升


页面分配

虚拟地址空间(VirtualAddressSpace,VAS)由很多的内存页面组成。这些页面有两种大小,32位系统是小的页面只有4KB大小(IA64位系统上是8KB)

64位系统上是大的页面有2MB大小(IA64位系统上是16MB)。

虚拟地址空间(VirtualAddressSpace,VAS)是由页面描述符表(简称页表)这种结构来维护的,因此,每个虚拟地址空间在页面描述符表里都有对应页面表入口

(个人感觉类似于系统服务描述符表SSDT ,内核描述符表GDT/LDT)。硬件利用这个表将这些入口转译出可读的格式,无论什么时候转译一个虚拟地址,

都必须去这张表找虚拟地址的入口。为了加快查找表上这些入口的速度,CPU维护了一块缓存叫做:Translation Look-Aside Buffer (TLB)

TLB的工作方式类似于SQLSERVER的执行计划缓存,只要一个入口曾经被转译过下次就不需要再次转译,大页的好处是提高TLB命中率,减少内核cpu消耗。

知道这个,就很容易去理解大的页

找不到有效主机,原因是 。 编码 500 详情 File "/usr/lib/python2.7/site-packages/nova/conductor/manager.py", line 1148, in schedule_and_build_instances instance_uuids, return_alternates=True) File "/usr/lib/python2.7/site-packages/nova/conductor/manager.py", line 742, in _schedule_instances return_alternates=return_alternates) File "/usr/lib/python2.7/site-packages/nova/scheduler/utils.py", line 787, in wrapped return func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/nova/scheduler/client/__init__.py", line 53, in select_destinations instance_uuids, return_objects, return_alternates) File "/usr/lib/python2.7/site-packages/nova/scheduler/client/__init__.py", line 37, in __run_method return getattr(self.instance, __name)(*args, **kwargs) File "/usr/lib/python2.7/site-packages/nova/scheduler/client/query.py", line 42, in select_destinations instance_uuids, return_objects, return_alternates) File "/usr/lib/python2.7/site-packages/nova/scheduler/rpcapi.py", line 158, in select_destinations return cctxt.call(ctxt, 'select_destinations', **msg_args) File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/client.py", line 174, in call retry=self.retry) File "/usr/lib/python2.7/site-packages/oslo_messaging/transport.py", line 131, in _send timeout=timeout, retry=retry) File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 559, in send retry=retry) File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 550, in _send raise result 已创建 Nov. 17, 2025, 7:49 a.m.
11-18
<think> 嗯,用户这次的问题很具体:在OpenStack环境创建虚拟机时遇到HTTP 500错误,提示"No valid host was found",同时给出了包含nova/conductor/manager.py的Python调用栈。这属于典型的调度失败问题,需要结合OpenStack架构和日志分析。 用户提供的引用材料很有价值,特别是引用[5]详细描述了nova-scheduler的调度流程。让我梳理关键点:当nova-api收到请求后,由nova-conductor调用ComputeTaskManager.build_instances()方法,进而触发nova-scheduler的select_destinations()进行主机筛选。错误发生在调度环节,说明没有任何计算节点能满足虚拟机需求。 可能的原因需要分层排查: 首先检查资源状态——虽然错误提示主机不可用,但实际可能是资源不足或策略冲突。比如用户申请的flavor需要16核128G内存,而集群最大节点只有8核64G。或者启用了特定调度策略(如AggregateInstanceExtraSpecsFilter)但未正确配置元数据。 其次是服务状态异常。引用[4]提到nova-compute通过消息队列通信,如果某个计算节点的rabbitmq连接中断,它的资源数据就不会更新到nova-scheduler数据库,导致调度器认为该节点离线。需要确认所有计算节点的nova-compute服务状态及时间同步。 用户提供的调用栈指向nova/conductor/manager.py,结合引用[2]提到的安全设计——nova-compute不能直连数据库,所有数据库操作都通过nova-conductor代理。因此还要检查nova-conductor与数据库的连接是否正常,是否有死锁或慢查询。 最隐蔽的情况是调度器配置问题。例如在nova.conf中配置了多个filters,但filter之间的逻辑冲突。假设同时使用RamFilter和AvailabilityZoneFilter,若可用域内所有节点内存不足,就会触发这个错误。需要检查filter执行顺序是否合理。 关于解决方案,分四级响应很必要:从最直接的资源调整(如更换flavor)到复杂的调度器调试(如检查filter组合)。特别要注意日志分析技巧——用户可能不知道需要同时检查nova-scheduler和nova-compute日志,这点必须强调。 用户能提供具体错误代码,说明已经查看过日志,有一定技术基础。因此回复可以包含操作细节,比如如何临时禁用strict策略(设置scheduler.max_attempts=3),但也要提醒这只适用于测试环境。 </think>在OpenStack创建虚拟机时遇到HTTP 500错误提示**"No valid host was found"**并伴随Python调用栈(含`nova/conductor/manager.py`),这通常表示**调度器无法找到满足条件的计算节点**。以下是系统级排查方案: --- ### **核心原因分析** 1. **资源不足**:请求的规格(Flavor)超出集群物理资源(CPU/RAM/磁盘) 2. **调度策略冲突**:主机聚合/AZ策略、过滤规则(Filter)阻止调度 3. **服务状态异常**:计算节点`nova-compute`服务未运行或未上报资源 4. **数据不同步**:`nova-scheduler`的缓存资源数据过期(需强制刷新) 5. **网络隔离**:目标网络/VLAN未绑定到计算节点 --- ### **详细解决步骤** #### 1. **检查计算节点状态** ```bash # 查看所有计算节点状态及资源 openstack hypervisor list openstack hypervisor show <ID> # 检查具体节点资源 # 确认nova-compute服务状态 systemctl status nova-compute* # 所有计算节点执行 ``` - ✅ **预期结果**:所有节点`State`为`up`,`Status`为`enabled` - ⚠️ **异常处理**:重启异常服务 `systemctl restart nova-compute` --- #### 2. **验证调度器日志** ```bash # 查看nova-scheduler关键日志(控制节点) grep "No valid host" /var/log/nova/nova-scheduler.log # 检查失败原因(常见输出示例) ERROR nova.scheduler.manager [req-xxx] NoValidHost: No valid host was found... ``` - 🔍 **日志线索**: - `Filter RamFilter returned 0 hosts` → 内存不足 - `No host matched AZ 'az1'` → 可用区配置错误 - `Network not available on host` → 网络未绑定 --- #### 3. **强制刷新调度器缓存** ```bash # 清空资源统计缓存(控制节点) nova-manage placement heal_allocations # 修复资源分配 nova-manage cell_v2 discover_hosts --verbose # 重新发现主机 ``` > **原理**:引用[2][5]指出`nova-compute`不直连DB,依赖`nova-conductor`更新资源。缓存过期会导致调度器使用旧数据。 --- #### 4. **调整调度策略** 修改`/etc/nova/nova.conf`中的调度器配置: ```ini [scheduler] # 放宽过滤条件(临时测试) enabled_filters = RetryFilter, AvailabilityZoneFilter, ComputeFilter # 增加调度尝试次数(默认值=3) max_attempts = 10 ``` 重启服务生效: ```bash systemctl restart nova-scheduler ``` --- #### 5. **检查网络配置** ```bash # 确认虚拟机网络绑定到计算节点 openstack network agent list # 检查L2/L3代理状态 openstack network show <Network_ID> # 查看可用物理网络 ``` - 💡 **关键点**:若使用**VLAN网络**,需确保目标计算节点接入相应物理网络[^4]。 --- #### 6. **降级规格测试** 创建最小规格测试实例: ```bash openstack flavor create --ram 512 --disk 5 --vcpus 1 test_flavor openstack server create --flavor test_flavor --image <Image_ID> test_vm ``` - ✅ **成功**:说明原Flavor资源需求过高 - ❌ **仍失败**:需检查底层虚拟化层(如Libvirt/KVM状态) --- ### **高级调试方案** 若以上步骤无效,启用**调度器详细日志**: ```ini # /etc/nova/nova.conf [scheduler] driver = filter_scheduler debug = true # 开启DEBUG日志 [filter_scheduler] available_filters = nova.scheduler.filters.all_filters enabled_filters = RetryFilter, AvailabilityZoneFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter ``` 重启服务后分析`nova-scheduler.log`中的**filter工作流**。 --- ### 根本原因总结 | 原因类型 | 发生概率 | 解决方案 | |------------------|----------|------------------------------| | 资源不足 | ★★★★☆ | 扩容节点/减少Flavor规格 | | 调度策略过严 | ★★★☆☆ | 调整Filter/AZ配置 | | 服务状态异常 | ★★☆☆☆ | 重启`nova-compute`服务 | | 网络隔离 | ★★☆☆☆ | 检查物理网络连接 | | 数据不同步 | ★☆☆☆☆ | 执行`nova-manage`命令刷新缓存 | > **重要提示**:引用[5]证实调度过程由`nova-conductor`调用`nova-scheduler`完成,若问题持续需检查`nova-conductor`与消息队列(RabbitMQ)的通信状态[^2][^5]。 --- ### 相关问题 1. 如何优化OpenStack调度器策略以提高虚拟机创建成功率? 2. Nova服务组件(nova-api/nova-scheduler/nova-conductor)之间的通信流程是怎样的? 3. 当出现`NoValidHost`错误时,如何通过修改Filter组合实现紧急容灾? 4. OpenStack中如何配置主机聚合(Host Aggregates)以隔离特定类型工作负载? 5. 虚拟机创建过程中,nova-compute服务与底层Hypervisor(如KVM)的交互机制是什么
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值