error

linux服务器进程打开文件过多导致服务异常
linux服务器进程打开文件过多导致服务异常
背景 我的logstash是多管道部署结果发现有大量日志丢失的情况查看logstash日志出现了以下报错 [2023-11-07T09:43:38,492][ERROR][logstash.javapipeline ][log] Pipeline worker error, the pipeline will be stopped {:pipeline_id=>“log”, :error=>"/var/lib/logstash/queue/log/checkpoint.head.tmp (Too many open files)", :exception=>Java::JavaIo::FileNotFoundException, :backtrace=>[“java.base/java.io.FileOutputStream.open0(Native Method)”, “java.base/java.io.FileOutputStream.open(FileOutputStream.java:298)”, “java.base/java.io.FileOutputStream.(FileOutputStream.java:237)”, “java.base/java.io.FileOutputStream.(FileOutputStream.java:187)”, “org.logstash.ackedqueue.io.FileCheckpointIO.write(FileCheckpointIO.java:105)”, “org.logstash.ackedqueue.Page.headPageCheckpoint(Page.java:202)”, 这个问题是 Logstash Pipeline 在处理数据时报错,原因是打开文件过多导致"Too many open files" 解决方法 1. 检查操作系统的文件打开数量限制,使用ulimit -n查看。如果太低,可以提高这个限制 打开 /etc/profile 增加ulimit 值 1vim /etc/profile 2## 增加,保存并退出 3ulimit -n 10240 4# 重载配置 5source /etc/profile 2. 适当增大Logstash的heap size,如-Xms和-Xmx设置为2g。 1vim /etc/logstash/jvm.option 2# 修改参数 3-Xms 2g 4-Xmx 2g 5# 重启logstash服务
解决Elasticsearch索引只读(read-only)
解决Elasticsearch索引只读(read-only)
背景 这两天有开发向我反馈说elasticsearch有报错,嘿,我定睛一看,这不是进入只读状态了,看来是存储达到额度,我马上加个新的数据节点,平衡一下存储压力 报错信息: 1Elasticsearch Error {type:cluster_block_exception,reason:”blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];} 新建服务器,安装elasticsearch 为了和之前的服务器一样,我简单写一下我elasticsearch版本和服务器系统版本 软件 版本 centos 7.9 elasticsearch 6.7.2 JDK 1.8.61 内存 32G 安装和配置elasticsearch 使用rpm 安装 1wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.7.2.rpm 1rpm --install elasticsearch-6.7.2.rpm 配置参数,进入/etc/elasticsearch目录 修改配置vim elasticsearch.yml 1# ======================== Elasticsearch Configuration ========================= 2 3cluster.name: cluster-prod-es # 集群名称 4 5node.name: node-x # 节点名称 6 7path.data: /var/lib/elasticsearch # 数据存储 8 9path.logs: /var/log/elasticsearch # 日志存储 10 11network.host: 192.168.0.170 # 主机IP地址 12 13http.port: 9200 # 端口号 14 15discovery.
Linux 系统收包流程以及内核参数优化
Linux 系统收包流程以及内核参数优化
简介 高并发的系统架构中,任何细微调整,稍有不注意便会引起连锁反应,只有系统地了解整个网络栈,在处理疑难杂症或者系统优化工作中,才能做到手中有粮心中不慌。在本节,我们概览一个 Linux 系统收包的流程,以便了解高并发系统所面临的性能瓶颈问题以及相关的优化策略。 收包过程 网卡 eth0 收到数据包。 网卡通过 DMA 将数据包拷贝到内存的环形缓冲区(Ring Buffer,在网卡中有 RX Ring 和 TX Ring 两种缓冲)。 数据从网卡拷贝到内存后, 网卡产生 IRQ(Interupt ReQuest,硬件中断)告知内核有新的数据包达到。 内核收到中断后, 调用相应中断处理函数,开始唤醒 ksoftirqd 内核线程处理软中断。 内核进行软中断处理,调用 NAPI poll 接口来获取内存环形缓冲区(ring buffer)的数据包,送至更上层处理。 内核中网络协议栈:L2 处理。 内核中网络协议栈:L3 处理。 内核中网络协议栈:L4 处理。 网络协议栈处理数据后,并将其发送到对应应用的 socket 接收缓冲区。 高并发瓶颈 用户进程调用系统调用陷入内核态的开销。 CPU 响应包的硬中断 CPU 开销 ksoftirqd 内核线程的软中断上下文开销。 RX/TX Ring 优化 处理一个数据包会有各类的中断、softirq 等处理,因为分配给 Ring Buffer 的空间是有限的,当收到的数据包速率大于单个 CPU 处理速度的时,Ring Buffer 可能被占满并导致新数据包被自动丢弃。一个 CPU 去处理 Ring Buffer 数据会很低效,这个时候就产生 RSS、RPS 等多核并发机制来提升内核网络包的处理能力。 但是注意,开启多核并发特性,会挤压业务代码的执行时间,如果业务属于 CPU 密集型,会导致业务性能下降。是否开启多核处理,需要根据业务场景考虑,根据笔者的经验来看,例如此类负载均衡服务器、网关、集群核心转发节点等网络I/O 密集型场景可以尝试优化 RSS、RPS 等配置。
Vue3 + vite + nginx项目部署后404问题
Vue3 + vite + nginx项目部署后404问题
Vue3 + vite + nginx项目部署后404问题 vue3 + vite + nginx 在服务器上部署后打开首页都没问题,打开其他路径全部 404。 nginx 报错日志:No such file or directory 其实查看 build 后的dist文件夹可以发现,只有一个index.html,当你访问别的路径时nignx查找不到所以就报错了 解决方案 在 nginx.conf 中添加: try_files $uri $uri/ /index.html; server { listen 80; server_name localhost; location / { root /dist; index index.html index.htm; # 在配置文件的此处加上这句话 try_files $uri $uri/ /index.html; } } 总结 其实上述改动就是告诉 nignx 找不到文件的时候就访问 index.html 就可以了。 究其原因其实就是是 vue3 的 router 使用了history模式,该模式与之前hash模式的具体区别可以自行百度一下,不在此赘述。
githubAction set-output弃用错误
githubAction set-output弃用错误
githubAction set-output 弃用错误 The set-output command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/ 原因 如果您有一个使用 设置输出的GitHub Actionsecho ::set-output key=value工作流程,您已经开始看到无用的弃用警告。这是修复它的方法。查看官方链接基本上得不到什么帮助! 修复方法 更新其它人的 action 方法 1将 @actions/core 提升到 1.10.0 修改自己的 aciton 方法 1run: echo "::set-output name=KEY::VALUE" 2## 改为 3run: echo "KEY=VALUE" >>$GITHUB_OUTPUT 建议:使用自己的方法 总结 平台经营者非常肆意妄为的修改自己的代码内容弃用功能,无限的权力滋生傲慢……我相信大部分开发这并没有注意到这个告警,知道流水线服务报错之后才会注意到,希望微软可以对能更加包容不同的开发者,尊重开发者社区。
k8s CNI 问题 连接认证失效
k8s CNI 问题 连接认证失效
k8s CNI 问题 连接认证失效 删除 calico 换成 flannel 后,容器没有正常启动 network: error getting ClusterInformation: connection is unauthorized: Unauthorized] 解决问题 删除掉 /etc/cni/net.d/ 目录下的 calico 配置文件即可。 要删除所有节点的配置文件 1sudo rm -rf /etc/cni/net.d/*calico* 不要重复网络插件
k8s.gcr.io国内无法连接解决方法
k8s.gcr.io国内无法连接解决方法
k8s.gcr.io 国内无法连接解决方法 Get https://k8s.gcr.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) 这个一看知道什么原因了,应该 GFW!那好吧,只能给 docker 加个代理了。 解决问题 添加 mirror 站点 1registry.cn-hangzhou.aliyuncs.com/google_containers
K8S 问题排查:cgroup 内存泄露问题
K8S 问题排查:cgroup 内存泄露问题
K8S 问题排查:cgroup 内存泄露问题 unable to ensure pod container exists: failed to create container for [kubepods besteffort pod5f26dae8-0421-4eab-a3f7-aa51c6848e2b] : mkdir /sys/fs/cgroup/memory/kubepods/besteffort/pod5f26dae8-0421-4eab-a3f7-aa51c6848e2b: cannot allocate memory 查看 linux 内核 1cat /proc/version 2uname -a 可以发现 linux 版本是 3.0 版本 原因 cgroup 的 kmem account 特性在 Linux 3.x 内核上有内存泄露问题,然后k8s用了这个特性,导致后面创建不出新的pod来了 解决方法 1# 修改/etc/default/grub 为 2GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rhgb quiet cgroup.memory=nokmem" 3#加上了 cgroup.memory=nokmem 4# 生成配置 5/usr/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg 6 7# 重启机器 8reboot 验证 1cat /sys/fs/cgroup/memory/kubepods/burstable/pod*/*/memory.kmem.slabinfo 输出信息 1cat: /sys/fs/cgroup/memory/kubepods/burstable/pod0fe273ca-42e0-4223-9fe8-16d8dd1774e9/0fdd5d9c16929fd600dbdf313b5c3ebabad912dc0cb076ed6e7799e028b31481/memory.
docker 问题处理
docker 问题处理
docker 无法启动 打开服务器输入docker ps,输出错误 Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? 怀疑是不是docker.services 部署没成功,systemctl start docker 启动 docker,结果服务器还是报错 Job for docker.service failed because the control process exited with error code. See “systemctl status docker.service” and “journalctl -xe” for details. systemctl status docker.service 输出日志: 1● docker.service - Docker Application Container Engine 2 Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled) 3 Active: failed (Result: exit-code) since Thu 2022-08-04 11:43:05 CST; 2min 57s ago 4TriggeredBy: ● docker.
ProXmoX VE升级 apt-get update 报错
ProXmoX VE升级 apt-get update 报错
ProXmoX VE 升级 apt-get update 报错 解决方法 1vim /etc/apt/sources.list.d/pve-enterprise.list 2#注释掉 3#deb https://enterprise.proxmox.com/debian/pve stretch pve-enterprise 添加内容 1echo "deb http://download.proxmox.com/debian/pve stretch pve-no-subscription" > /etc/apt/sources.list.d/pve-install-repo.list 2wget http://download.proxmox.com/debian/proxmox-ve-release-5.x.gpg -O /etc/apt/trusted.gpg.d/proxmox-ve-release-5.x.gpg 更新系统 1apt update && apt dist-upgrade 结尾 升级完成后,可以执行pveversion -v查看下最新的软件版本。然后执行reboot重启物理服务器
安装 docker 出现 ERROR: Unsupported distribution 'ol' 问题
安装 docker 出现 ERROR: Unsupported distribution 'ol' 问题
安装 docker 出现 ERROR: Unsupported distribution ‘ol’ 问题 部署 docker 安装出现 ERROR: Unsupported distribution ‘ol’ 确认是不是 arm 架构 1uname -r 确认使用的是不是 oracle 服务器系统,如果是请继续操作,安装依赖: 1dnf install -y dnf-utils zip unzip 2dnf config-manager --add-repo=https://download.docker.com/linux/centos/docker-ce.repo 安装 docker 1dnf remove -y runc 2dnf install -y docker-ce --nobest 完成 docker 安装并检查 1systemctl enable docker.service 2systemctl start docker.service 1#检查 2systemctl status docker.service 3docker info 4docker version 结尾 该问题主要是 oracle 没有支持依赖导致的~oracle 还是很不错的~