解决texlive化学式转换镜偶尔工艺堆积导致的卡死问题。
前言
在用python清理超时pdflatex僵尸进程的博文中，我用Python脚本启动了清理pdflatex僵尸进程的定时任务。部署了三个在线的4u2G k8s pod，pdflatex的执行过程是cpu密集型的，内存消耗很少。然而，在PODs的实际操作中有时会出现一些问题。
问题
问题1: K8s POD存储超过100M，POD宕机，但资源没有回收，导致K8s命名空间资源空耗。
问题2:每隔一段时间，单个pod进程偶尔会出现积压，预定的清理脚本也会宕机，导致清理任务无法正常运行。
问题3:主要原因是你不知道吊舱有问题。所有请求都通过k8s负载平衡到每个pod。一旦路由到有问题的pod，请求就会挂起。您必须在本地配置kubectl，以进入生产窗格检查流程，找到问题窗格，手动清理流程并重新启动清理任务。但是清理完之后，你会发现同样的问题过几天还会再次出现，人力运维的负担很重。
解决
问题一
第一个问题是，当我们执行pdflatex时，我们会生成tex和pdf文件，正常执行后，我们会清理这些文件。但是如果是僵尸进程，我们在清理进程的时候也需要清理进程对应的文件。清理脚本如下：
def clean_files():
nowtime=datetime.datetime.now()
#获得5分钟的时间差(因为创建超过5分钟的文件需要删除)
deltime=datetime.timedelta(秒=120)
#获取当前时间减去5分钟时差。
nd=nowtime - deltime
路径='/home/'
files=os.listdir(路径)
对于文件：中的文件
filectime=get_filectime(路径文件)
if filectime nd和len(文件)32:
os.remove(路径文件)
Logging.info('清理文件：'文件')
问题二
第二个问题比较严重，这是由以下原因造成的：
1.clean_files的偶尔异常导致计划任务挂起。在这里，已经判断偶尔出现了一个异常，即在文件创建时间后5分钟删除文件时找不到文件，这导致计划的任务挂起。判断pdflatex进程的积压导致clean_files永远无法获得cpu的执行权，而那些“异常”的文件在os.remove执行时被“正常”进程清理掉，导致错误。
2.p.terminate()方法没有生效。这个应该是texlive的bug引起的。我在部署生产时，每10分钟执行一次前面的清理过程。但由于pdflatex的cpu消耗较高，如果出现较多不正确的语法转换或稍高的并发，会造成短时间内cpu压力突然增大。此时，一些pdflatex进程已经伪造了它们的死亡，进程不能通过向进程发送终止指令来直接响应。
解决方法：第一个问题比较简单。试着抓住它。如果一次失败，下次可以执行，没有坏处。第二个问题，问题一直没有定位，偶尔有一些节点已经运行了几个月没有任何问题，但是偶尔有一个新的节点总是喜欢出问题，除了暴力和代码什么都没有。
def process_checker():
尝试：
Logging.info('pdflatex进程清理')
OS . system(' kill-9 ` PS-ef | grep pdflatex | grep pdftex | awk ' { print $ 1 } ' ` ')
e:除外
日志记录。错误(“清理过程中的错误”)
尝试：
clean_files()
Logging.info(“文件清理成功”)
e:除外
日志记录。错误(“清理文件时出错”)
其实一开始我用kill让它更流畅，但是跑了一段时间后发现根本摆脱不了kill，于是加了-9结束那些烦人的进程。
定时任务也会被删除。一切都很简单，边循环，每次睡60秒。循环中的代码try catch保证了如果一个节点在高峰期卡住，一分钟之内就能自动恢复，避免了人肉操作和维护，在生产环境中增加了两个实例，不存在长时间卡住的反馈问题。
内容来源网络，如有侵权，联系删除，本文地址：https://www.230890.com/zhan/130344.html