首页 > 系统相关 >优化Linux服务性能：深度解析 systemctl 与资源限制

优化Linux服务性能：深度解析 systemctl 与资源限制

时间：2024-11-28 20:30:30浏览次数：9  
标签：限制 用户 systemctl Linux 进程 服务 解析 资源

在Linux系统中，合理配置资源限制（如最大文件描述符数、最大进程数等）对于确保服务的稳定性和性能至关重要。然而，许多开发者在配置了limit限制后，发现通过systemctl启动的服务进程仍然出现诸如“Too many open files”的错误。这背后的原因主要涉及到systemd与PAM（Pluggable Authentication Modules）的交互方式。本文将全面解析这一问题，并提供详细的性能优化方案，确保通过systemctl启动的服务能够正确继承并应用所需的资源限制。

文章目录

一、问题描述

在配置了资源限制（如ulimit）后，为什么通过systemctl启动的进程仍然会报错，例如：

java.net.SocketException: Too many open files

这种现象的根本原因在于，systemctl启动的服务默认不继承用户Shell或PAM配置的资源限制。

二、Linux中的资源限制类型及其适用范围

在Linux中，资源限制（软限制和硬限制）可以分为操作系统级别、用户级别和进程级别，具体适用范围取决于资源限制的类型和配置方式。以下是对这些限制的范围和适用性的详细说明：

1. 进程级别的限制

  • 适用范围: 资源限制是针对单个进程施加的，每个进程的限制是独立的。
  • 设置方式:
    • 通过ulimit或程序调用setrlimit()设置。
    • 软限制和硬限制直接影响进程的资源使用。
  • 典型限制:
    • 最大文件描述符数（nofile）: 限制单个进程可以打开的文件句柄数量。
    • 最大堆栈大小（stack）: 限制进程的栈内存使用（超过限制会导致Segmentation Fault）。
    • 最大核心转储文件大小（core）: 限制进程生成的核心转储文件大小。
    • CPU时间限制（cpu）: 限制进程能消耗的CPU时间。
    • 地址空间大小（as）: 限制进程可以使用的虚拟内存总量。
示例：

使用ulimit设置进程级限制：

ulimit -n 512  # 将当前Shell会话中所有进程的最大文件描述符数限制为512

通过C程序调整限制：

#include <sys/resource.h>
#include <stdio.h>

int main() {
    struct rlimit rl;
    getrlimit(RLIMIT_NOFILE, &rl);
    printf("Current Soft Limit: %ld\n", rl.rlim_cur);
    printf("Current Hard Limit: %ld\n", rl.rlim_max);

    rl.rlim_cur = 512;  // 修改软限制
    setrlimit(RLIMIT_NOFILE, &rl);
    printf("Soft Limit Updated to: %ld\n", rl.rlim_cur);

    return 0;
}
特点：
  • 进程级别的限制是最细粒度的限制，作用于单个进程。
  • 子进程会继承父进程的限制（包括软限制和硬限制）。
  • 用户可以在硬限制范围内调整软限制。

2. 用户级别的限制

  • 适用范围: 针对某个用户运行的所有进程的总资源使用限制。
  • 设置方式:
    • 通过/etc/security/limits.conf或/etc/security/limits.d/*.conf文件设置。
    • 使用PAM（Pluggable Authentication Modules）模块控制用户的资源限制。
  • 典型限制:
    • 最大同时登录会话数（maxlogins）: 限制用户的并发登录会话数。
    • 最大用户进程数（nproc）: 限制用户可以运行的最大进程数。
    • 最大打开文件数（nofile）: 限制用户所有进程的文件句柄总数。
    • 虚拟内存限制（as）: 限制用户进程可以使用的虚拟内存总量。
示例：

在/etc/security/limits.conf中设置用户级别限制：

# 格式：<用户或组> <类型> <资源> <值>
username    soft    nofile    1024   # 设置软限制为1024
username    hard    nofile    2048   # 设置硬限制为2048
username    soft    nproc     100    # 限制最大进程数为100

通过ulimit查看用户级别限制（当前Shell会话的限制）：

ulimit -u  # 查看当前用户的最大进程数限制
特点：
  • 用户级别限制是针对某用户的资源使用总量。
  • 用户所有的进程共享这些限制，例如nproc限制一个用户能运行的最大进程数。
  • 用户级别限制通常由管理员设置，普通用户无法修改。

3. 操作系统级别的限制

  • 适用范围: 针对整个系统的资源使用限制，限制所有用户和进程的资源总量。
  • 设置方式:
    • 调整内核参数（通过/etc/sysctl.conf或sysctl命令）。
    • 修改/proc/sys/下的内核参数。
  • 典型限制:
    • 最大文件描述符数（fs.file-max）: 限制整个系统可以打开的文件描述符总数。
    • 最大进程数（kernel.pid_max）: 限制系统可以创建的进程总数。
    • 共享内存段大小（kernel.shmmax）: 限制单个共享内存段的最大大小。
    • 虚拟内存参数（vm.*）: 控制系统的内存管理行为。
示例：

查看和调整系统级限制：

# 查看系统的最大文件描述符限制
cat /proc/sys/fs/file-max

# 临时调整系统的最大文件描述符限制
echo 2097152 > /proc/sys/fs/file-max

# 永久修改系统限制（编辑 /etc/sysctl.conf 文件）
echo "fs.file-max = 2097152" >> /etc/sysctl.conf
sysctl -p  # 使配置生效

举例：限制整个系统的最大进程数：

cat /proc/sys/kernel/pid_max
echo 65535 > /proc/sys/kernel/pid_max
特点：
  • 操作系统级限制是全局性的，适用于所有用户和进程。
  • 这些限制通常由系统管理员设置，用于保护系统稳定性。
  • 许多系统级限制是内核参数，直接影响内核的资源分配策略。

总结：限制的适用范围对比

限制类型适用范围示例资源设置权限
进程级别单个进程最大打开文件数、CPU时间、堆栈大小用户可调整（软限制）
用户级别某个用户运行的所有进程最大进程数、登录会话数、文件数管理员设置
操作系统级别整个系统（影响所有用户和进程）文件句柄总数、最大进程数、共享内存管理员设置

设计的目的

  1. 进程级别限制：

    • 控制单个进程的资源使用，防止单个程序消耗过多资源（例如打开过多文件或占用过多内存）。
    • 适用于细粒度的资源管理。

  2. 用户级别限制：

    • 控制单个用户占用的资源总量，防止某用户滥用系统资源。
    • 适用于多用户环境下的资源隔离。

  3. 操作系统级别限制：

    • 确保整个系统资源使用的稳定性，防止系统资源被耗尽。
    • 适用于全局性的资源管理和调优。

通过这些限制的分级设计，Linux提供了灵活且强大的资源控制机制，从而确保系统性能和稳定性，即使在多用户或高负载环境下也能正常运行。

三、systemctl启动服务不继承Shell限制的原因

  • 独立的启动环境：systemctl启动的服务运行在systemd提供的独立环境中，与用户的Shell会话隔离。
  • 不依赖PAM：默认情况下，systemd启动服务时不加载PAM，会话中的资源限制配置（如/etc/security/limits.conf）因此不生效。
  • 资源管理机制：systemd提供独立的资源管理机制，默认使用系统的全局限制，而不是用户Shell的配置。

四、为systemctl启动的服务正确配置资源限制

为了让systemctl启动的服务进程能够应用类似/etc/security/limits.d/的限制，可以通过以下几种方式解决：

方法一：在服务文件中显式配置资源限制（推荐）

systemd提供了一系列资源限制参数，直接在服务文件中配置是最清晰、最可靠的方式。

步骤：

  1. 编辑服务文件：

    sudo systemctl edit myservice.service

  2. 添加资源限制配置：
    在[Service]部分中，添加以下内容：

    [Service]
LimitNOFILE=65535                # 设置最大文件描述符数
LimitNPROC=4096                   # 设置最大进程数
LimitSTACK=8388608               # 设置堆栈大小（KB）

  3. 重载并重启服务：

    sudo systemctl daemon-reload
sudo systemctl restart myservice.service

  4. 验证配置：

    systemctl show myservice.service | grep -i "Limit"

方法二：修改systemd全局默认限制

如果希望所有通过systemctl启动的服务默认使用更高的资源限制，可以修改systemd的全局配置文件。

步骤：

  1. 编辑全局配置文件：

    sudo nano /etc/systemd/system.conf

    或（针对用户级服务）：

    sudo nano /etc/systemd/user.conf

  2. 设置默认限制：
    添加或修改以下内容：

    DefaultLimitNOFILE=65535         # 文件描述符限制
DefaultLimitNPROC=4096            # 进程数限制
DefaultLimitSTACK=8388608        # 堆栈大小限制（KB）

  3. 重载systemd配置：

    sudo systemctl daemon-reexec

  4. 重启服务以应用新限制。

方法三：启用PAM支持以继承/etc/security/limits.d/配置

如果希望systemctl启动的服务继承/etc/security/limits.conf或/etc/security/limits.d/中的限制，可以启用PAM会话支持。

步骤：

  1. 编辑服务文件：

    sudo systemctl edit myservice.service

  2. 添加PAM支持：
    在[Service]部分添加以下内容：

    [Service]
PAMName=login

  3. 确保PAM配置正确：
    确认/etc/pam.d/login包含：

    session required pam_limits.so

  4. 重载并重启服务：

    sudo systemctl daemon-reload
sudo systemctl restart myservice.service

方法四：通过EnvironmentFile显式加载限制

可以通过systemd的EnvironmentFile选项加载自定义的环境变量，用于设置限制。

步骤：

  1. 创建环境文件：

    sudo nano /etc/systemd/system/myservice-env.conf

    添加内容：

    ULIMIT_NOFILE=2048

  2. 修改服务文件：

    sudo systemctl edit myservice.service

    添加：

    [Service]
EnvironmentFile=/etc/systemd/system/myservice-env.conf
ExecStartPre=/bin/sh -c "ulimit -n ${ULIMIT_NOFILE}"

  3. 重载并重启服务：

    sudo systemctl daemon-reload
sudo systemctl restart myservice.service

五、验证服务的资源限制是否生效

无论使用哪种方法，都可以通过以下方式验证服务进程的资源限制是否生效：

  1. 检查进程限制：
    找到服务的进程PID并查看/proc/<PID>/limits文件：

    SERVICE_PID=$(pgrep -f myservice)
cat /proc/$SERVICE_PID/limits

    输出示例：

    Limit                     Soft Limit           Hard Limit           Units
Max open files            65535                65535                files
Max user processes        4096                 4096                 processes
Max stack size            8388608              8388608              KB

  2. 使用systemctl show查看服务配置：

    systemctl show myservice.service | grep -i "Limit"

    输出示例：

    LimitNOFILE=65535
LimitNPROC=4096
LimitSTACK=8388608

六、性能优化建议

为了确保通过systemctl启动的服务能够高效且稳定地运行，以下是一些性能优化建议：

  1. 合理配置资源限制：
    根据服务的实际需求，适当调整nofile、nproc等限制，避免因资源不足导致服务崩溃。例如，对于高并发的Web服务，适当增加nofile限制可以防止文件描述符耗尽。

  2. 监控资源使用：
    定期监控服务的资源使用情况，确保配置的限制能够满足业务需求。使用工具如top、htop、vmstat、lsof等，实时查看资源消耗。

  3. 优化代码和配置：

    • 减少不必要的文件描述符：确保应用程序在不需要时及时关闭文件描述符，防止泄漏。
    • 优化进程管理：避免频繁创建和销毁进程，使用线程或连接池等技术提升资源利用效率。
    • 调整应用配置：根据资源限制，合理配置应用程序的并发数、缓存大小等参数。

  4. 全局系统优化：

    • 调整系统范围的文件描述符限制：例如，通过调整fs.file-max来增加系统可打开的文件描述符总数。
    • 优化内存管理：调整内核参数如vm.swappiness、vm.overcommit_memory等，以提升内存利用率和系统性能。

  5. 选择合适的服务管理策略：

    • 分布式部署：对于高负载服务，考虑分布式部署，将负载分摊到多个实例。
    • 负载均衡：使用负载均衡器（如Nginx、HAProxy）合理分配请求，避免单一服务实例过载。

七、注意事项

  1. 优先级处理：

    • 服务文件中显式设置的限制优先于全局默认配置。
    • systemd的限制是独立的，与PAM不直接冲突，但默认情况下不会加载/etc/security/limits.d/。

  2. 用户权限：

    • 确保服务运行用户具有足够的权限来应用所需的资源限制。
    • 例如，非特权用户可能无法设置过高的文件描述符限制。

  3. 系统范围限制：

    • 即使在systemd中设置了高限制，仍可能受系统范围的限制（如/proc/sys/fs/file-max）影响。

    • 可以通过以下命令查看和调整系统范围的文件描述符限制：

      cat /proc/sys/fs/file-max
echo 2097152 > /proc/sys/fs/file-max

  4. 针对特定服务的定制化：

    • 某些服务（如Nginx、MySQL等）可能需要在自身的配置文件中单独调整资源限制。
    • 例如，Nginx中的worker_connections参数需要与系统的nofile限制相匹配。

  5. 验证配置后的系统稳定性：

    • 在调整资源限制后，确保系统和服务在高负载情况下仍能稳定运行。
    • 进行压力测试，模拟高并发场景，观察服务和系统的表现。

八、总结

默认情况下，systemctl启动的服务不会继承Shell或PAM的资源限制配置，而是依赖systemd的独立机制来管理资源。为服务正确配置资源限制，推荐使用以下方法：

  1. 在服务文件中显式配置限制（推荐）。
  2. 修改systemd的全局默认限制。
  3. 启用PAM支持以继承/etc/security/limits.conf的配置。
  4. 通过EnvironmentFile加载自定义限制（适用于特殊需求）。

通过正确配置资源限制，可以确保服务运行在符合业务需求的环境中，同时避免资源不足或资源滥用导致的问题。结合本文提供的性能优化建议和注意事项，可以进一步提升服务的稳定性和性能，确保在高负载和多用户环境下系统的高效运行。

标签：限制,用户,systemctl,Linux,进程,服务,解析,资源
From： https://blog.csdn.net/yhkal/article/details/144082080

相关文章

  • 【开发】计算机延迟指标全解析：深入理解系统性能瓶颈
    在计算机的世界里，“速度”一直是我们不懈追求的目标。从早期的计算机到如今的高性能设备，每一次技术进步都伴随着对速度的极致渴望。无论是处理器的运算速度，还是数据的传输与存储速度，都直接影响着我们使用计算机的体验。那你是否曾好奇，计算机中的“快”究竟是如何衡量的呢？今天，就让......
  • golang实现比特币内核:区块链交易“transaction“二进制数据结构解析和代码实现1
    对于比特币，最重要的组成部分是交易。如果你需要通过比特币与他人交易，你可能需要像支付购买商品或服务一样，将一些比特币发送给他人。交易有四个关键字段，它们是版本、输入、输出和锁定时间。交易的二进制内容可能因不同的版本而有所不同，我们需要解析版本号以决定如何解码交易......
  • Linux安装Redis并配置开机自启
    我这边是CentOS7系统的，然后我准备安装Redis6.2首先是去官网下载Redis安装包，可以看到这里面有所有的安装包，不会下载的可以直接找我要（Redis官方下载地址）下载下来后我们把它传到服务器，我这边是放在了/usr/local目录下，然后我们给它解压tar-zxvfredis-6.2.13.tar.gz......
  • 深入解析：使用Python爬取Bilibili视频
    深入解析：使用Python爬取Bilibili视频前提声明爬虫应遵守目标网站的robots.txt协议，尊重版权和用户隐私。本代码仅供学习和研究使用，不得用于商业用途。请确保在合法合规的前提下使用本代码。本代码所爬视频为公开可下载的视频目录前提声明引言环境准备代码解析1.导入必......
  • 我的无线转有线linux服务器用到的脚本们
    lnxrouter/home/light/Scripts/lnxrouterroute.sh/home/light/Scripts/route.sh#!/bin/bashsudo/home/light/Scripts/lnxrouter-ienp2s0-g0--daemonroute.service/etc/systemd/system/route.service[Unit]Description=runlnxrouterBefore=getty@tty1.servic......
  • 深度学习基本单元结构与输入输出维度解析
    深度学习基本单元结构与输入输出维度解析在深度学习领域，模型的设计和结构是理解其性能和应用的关键。本文将介绍深度学习中的基本单元结构，包括卷积神经网络（CNN）、反卷积（转置卷积）、循环神经网络（RNN）、门控循环单元（GRU）和长短期记忆网络（LSTM），并详细讨论每个单元的输入和输出维度......
  • YASKAWA安川机器人DX100轴控制基板维修解析知识
    ASKAWA安川机器人DX100轴控制基板的维修是一项复杂而精细的工作，要求具备丰富的知识和实践经验。通过与子锐机器人维修联系，希望能企业提供一些有益的参考和帮助，在面对轴板故障时能够迅速准确地找到问题所在并妥善处理。一、YASKAWA安川机器人维修步骤与方法1、故障诊断：通过YASKA......
  • Linux下端口连通性测试
    端口连通性测试使用nc命令Linux下自带/dev/tcp命令#!/bin/bash#检测脚本传入的参数if[$#-eq0];thenecho"使用格式:$0<IPPORT>|-f<file>"echo"<IPPORT>测试单个IP和端口"echo"-f<file>批量测试，使用参数-f指定要测试......
  • 7. Spring Cloud Sleuth+ZipKin 链路监控的配置详细解析
    7.SpringCloudSleuth+ZipKin链路监控的配置详细解析@目录7.SpringCloudSleuth+ZipKin链路监控的配置详细解析前言:1.SpringCloudSleuth+ZipKin的概述1.1Sleuth/ZipKin是什么？1.2Sleuth和Zipkin的简单关系图：1.3Sleuth工作原理解析2.Sleuth+ZipKin的......
  • TextIn文档解析表格处理模型优化，显著提升表格解析性能
    近期，TextIn通用文档解析最新推出表格处理优化版本。此前版本中，表格解析处理针对有线表格与无线表格预先分类，并基于框线进行模型预测。在运行过程中，我们发现，分类错误问题对表格解析准确率有负面影响。本次优化主要改善了表格识别效果，以统一方案替代有线表格与无线表格分类处理方法，......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99