本文主要是介绍Systemd服务配置排坑-TasksMax参数,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
一、背景
由于产品是Java程序,之前都是通过封装的start.sh运行即可。但是出于架构调整,改换为Ansible进行自动化部署,同时改用Systemd service的方式来对程序进行管理。
但不知道为啥原因,使用systemctl启动这个程序,就会无脑报错。 报错信息看起来像是我们使用到nacos,一直停留在无法创建新的线程、堆内存溢出:
晚上申请割接窗口时间进行排查,排查了2天都没排查出个所以然。 更奇怪的是,我们直接使用start.sh的方式能正常启动,但是使用systemctl 启动服务的方式就是死活起不来,这才是最坑的地方。
从报错信息,我们以为是ulimit设置的文件句柄限制太小,查看了一下ulimit -a, 发现限制量是100w, 应该不是这个问题。
也看了下nacos的端口可以正常访问,程序给了40G堆内存。并且是服务启动就报错咯,而不是运行起来才报错。 也没有生成dump文件。jstack分析了下线程运行情况,也正常。 百思不得其解。
最后,我们根据现象大概率判断可能是我们的systemd service哪里出了问题,要不然无法解释为啥同样的程序,通过start.sh启动可以正常,但是通过systemd的方式起不来。
二、排查过程
1、查看service文件,发现参数LimitNOFILE
刚开始我们发现service文件存在这个参数LimitNOFILE=81920, 以为是这个参数导致的。后面尝试把这个参数注释掉,重新启动发现还是一样起不来。
那根本原因还是没找到,只能继续排查。
2、TasksMax参数
后面使用systemctl start service, 直接通过systemcl status service观察服务的运行状态,看下是什么原因挂掉的。 此时发现了一个有趣的现象:
这里有一个limit的限制,还没修复之前是512, Tasks的数量一直在涨,大于>=limit 512以后,整个service也挂了。
很符合我们观察到的启动现象。
查询了一下资料,这个参数的含义:
systemd的TasksMax参数用于限制systemd管理的服务的并发线程数。当服务的线程数达到这个限制时,新线程的创建将会失败,并可能导致服务出现错误或不稳定。TasksMax参数可以在系统级别或进程级别进行设置。系统级别的设置影响所有systemd管理的服务,而进程级别的设置则只影响特定的服务。TasksMax参数的作用和设置方法主要包括以下几点:限制并发线程数:TasksMax参数设定了一个服务可以创建的线程数的上限。这有助于防止因线程过多而导致的资源耗尽和服务崩溃。
系统级别设置:在系统级别,TasksMax参数可以在/etc/systemd/system.conf文件中进行设置。例如,可以将DefaultTasksMax的值修改为5120,以允许服务创建更多的线程。
原来是systemd限定了进程的并发线程数量, 超过了则这个service会被systemd干掉。 顺藤摸瓜,我们看下这个默认值limit是不是512? 怎么修改参数值?
systemctl show --property=DefaultTasksMax
还真是512.对应得上了。 那么我们尝试修改下这个service的TaskLimit参数限制,调整到了10000.再尝试启动程序看是否正常,此时发现程序已经正常启动,不会挂了。
三、总结
针对systemd的配置信息,需要我们详细的去了解相关参数,才能写出较少的坑的sevrice文件。
我们可以直接通过systemctl --show | grep 的方式来过滤一些关键词,从而学习这些配置项的含义,要不然遇到这种坑真的难以排查。
这篇关于Systemd服务配置排坑-TasksMax参数的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!