5.5. 巨页

了解并配置巨页。

5.5.1. 巨页的作用
复制链接

内存在块（称为页）中进行管理。在大多数系统中，页的大小为 4Ki。1Mi 内存相当于 256 个页，1Gi 内存相当于 256,000 个页。CPU 有内置的内存管理单元，可在硬件中管理这些页的列表。Translation Lookaside Buffer (TLB) 是虚拟页到物理页映射的小型硬件缓存。如果在硬件指令中包括的虚拟地址可以在 TLB 中找到，则其映射信息可以被快速获得。如果没有包括在 TLN 中，则称为 TLB miss。系统将会使用基于软件的，速度较慢的地址转换机制，从而出现性能降低的问题。因为 TLB 的大小是固定的，因此降低 TLB miss 的唯一方法是增加页的大小。

巨页指一个大于 4Ki 的内存页。在 x86_64 构架中，有两个常见的巨页大小: 2Mi 和 1Gi。在其它构架上的大小会有所不同。要使用巨页，必须写相应的代码以便应用程序了解它们。Transparent Huge Pages（THP）试图在应用程序不需要了解的情况下自动管理巨页，但这个技术有一定的限制。特别是，它的页大小会被限为 2Mi。当有较高的内存使用率时，THP 可能会导致节点性能下降，或出现大量内存碎片（因为 THP 的碎片处理）导致内存页被锁定。因此，有些应用程序可能更适用于（或推荐）使用预先分配的巨页，而不是 THP。

5.5.2. 应用程序如何使用巨页
复制链接

节点必须预先分配巨页以便节点报告其巨页容量。一个节点只能预先分配一个固定大小的巨页。

巨页可以使用名为 hugepages-<size> 的容器一级的资源需求被消耗。其中 size 是特定节点上支持的整数值的最精简的二进制标记。例如：如果某个节点支持 2048KiB 页大小，它将会有一个可调度的资源 hugepages-2Mi。与 CPU 或者内存不同，巨页不支持过量分配。

apiVersion: v1
kind: Pod
metadata:
  generateName: hugepages-volume-
spec:
  containers:
  - securityContext:
      privileged: true
    image: rhel7:latest
    command:
    - sleep
    - inf
    name: example
    volumeMounts:
    - mountPath: /dev/hugepages
      name: hugepage
    resources:
      limits:
        hugepages-2Mi: 100Mi 
        memory: "1Gi"
        cpu: "1"
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

apiVersion: v1
kind: Pod
metadata:
  generateName: hugepages-volume-
spec:
  containers:
  - securityContext:
      privileged: true
    image: rhel7:latest
    command:
    - sleep
    - inf
    name: example
    volumeMounts:
    - mountPath: /dev/hugepages
      name: hugepage
    resources:
      limits:
        hugepages-2Mi: 100Mi


        memory: "1Gi"
        cpu: "1"
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

Copy to Clipboard

Toggle word wrap

1: 为巨页指定要分配的准确内存数量。不要将这个值指定为巨页内存大小乘以页的大小。例如，巨页的大小为 2MB，如果应用程序需要使用由巨页组成的 100MB 的内存，则需要分配 50 个巨页。OpenShift Container Platform 会进行相应的计算。如上例所示，您可以直接指定 100MB 。

分配特定大小的巨页

有些平台支持多个巨页大小。要分配指定大小的巨页，在巨页引导命令参数前使用巨页大小选择参数hugepagesz=<size>。<size> 的值必须以字节为单位，并可以使用一个可选的后缀 [kKmMgG]。默认的巨页大小可使用 default_hugepagesz=<size> 引导参数定义。

巨页要求

巨页面请求必须等于限制。如果指定了限制，则它是默认的，但请求不是。
巨页在 pod 范围内被隔离。容器隔离功能计划在以后的版本中推出。
后端为巨页的 EmptyDir 卷不能消耗大于 pod 请求的巨页内存。
通过带有 SHM_HUGETLB 的 shmget() 来使用巨页的应用程序，需要运行一个匹配 proc/sys/vm/hugetlb_shm_group 的 supplemental 组。

5.5.3. 在引导时配置巨页
复制链接

节点必须预先分配在 OpenShift Container Platform 集群中使用的巨页。保留巨页的方法有两种：在引导时和在运行时。在引导时进行保留会增加成功的可能性，因为内存还没有很大的碎片。Node Tuning Operator 目前支持在特定节点上分配巨页。

流程

要减少节点重启的情况，请按照以下步骤顺序进行操作：

通过标签标记所有需要相同巨页设置的节点。

oc label node <node_using_hugepages> node-role.kubernetes.io/worker-hp=

$ oc label node <node_using_hugepages> node-role.kubernetes.io/worker-hp=

Copy to Clipboard

Toggle word wrap

创建一个包含以下内容的文件，并把它命名为 hugepages_tuning.yaml：

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: hugepages 
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile: 
  - data: |
      [main]
      summary=Boot time configuration for hugepages
      include=openshift-node
      [bootloader]
      cmdline_openshift_node_hugepages=hugepagesz=2M hugepages=50 
    name: openshift-node-hugepages

  recommend:
  - machineConfigLabels: 
      machineconfiguration.openshift.io/role: "worker-hp"
    priority: 30
    profile: openshift-node-hugepages

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: hugepages


  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:


  - data: |
      [main]
      summary=Boot time configuration for hugepages
      include=openshift-node
      [bootloader]
      cmdline_openshift_node_hugepages=hugepagesz=2M hugepages=50


    name: openshift-node-hugepages

  recommend:
  - machineConfigLabels:


      machineconfiguration.openshift.io/role: "worker-hp"
    priority: 30
    profile: openshift-node-hugepages

Copy to Clipboard

Toggle word wrap

1: 将 Tuned 资源的 name 设置为 hugepages。
2: 将 profile 部分设置为分配巨页。
3: 请注意，参数顺序是非常重要的，因为有些平台支持各种大小的巨页。
4: 启用基于机器配置池的匹配。

创建 Tuned hugepages 对象

oc create -f hugepages-tuned-boottime.yaml

$ oc create -f hugepages-tuned-boottime.yaml

Copy to Clipboard

Toggle word wrap

创建一个带有以下内容的文件，并把它命名为 hugepages-mcp.yaml：

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: worker-hp
  labels:
    worker-hp: ""
spec:
  machineConfigSelector:
    matchExpressions:
      - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,worker-hp]}
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/worker-hp: ""

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: worker-hp
  labels:
    worker-hp: ""
spec:
  machineConfigSelector:
    matchExpressions:
      - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,worker-hp]}
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/worker-hp: ""

Copy to Clipboard

Toggle word wrap

创建机器配置池：
```
oc create -f hugepages-mcp.yaml
```
```
$ oc create -f hugepages-mcp.yaml
```
Copy to Clipboard Toggle word wrap

因为有足够的非碎片内存，worker-hp 机器配置池中的所有节点现在都应分配 50 个 2Mi 巨页。

oc get node <node_using_hugepages> -o jsonpath="{.status.allocatable.hugepages-2Mi}"

$ oc get node <node_using_hugepages> -o jsonpath="{.status.allocatable.hugepages-2Mi}"
100Mi

Copy to Clipboard

Toggle word wrap

注意

TuneD bootloader 插件只支持 Red Hat Enterprise Linux CoreOS (RHCOS) worker 节点。

返回顶部

5.5. 巨页

5.5.1. 巨页的作用
复制链接

5.5.2. 应用程序如何使用巨页
复制链接

5.5.3. 在引导时配置巨页
复制链接

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

5.5. 巨页

5.5.1. 巨页的作用复制链接链接已复制到粘贴板!

5.5.2. 应用程序如何使用巨页复制链接链接已复制到粘贴板!

5.5.3. 在引导时配置巨页复制链接链接已复制到粘贴板!

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

5.5.1. 巨页的作用
复制链接

5.5.2. 应用程序如何使用巨页
复制链接

5.5.3. 在引导时配置巨页
复制链接