前言业务用了NAS写入了大量的文件, 大概半小时10万吧。 然后就没办法写入了, 执行一下 echo 1 > a.txt 都要30s左右。
原因找nas那边同学看了一下。总结是原因: 单目录文件太多，并且代码中有 readdir的操作，导致卡死。
read dir时 如果出现创建或者删除文件，会触发重新readdir，如果两者有并发，并且文件数量多，肯定是readdir会很慢。后台统计你们97%的OP都是readdir，且量比较大.
既然没办法，那就先删吧。
结果使用之前有写过如何高效的删除百万文件. 删不掉。
实际上删除之前会 readdir，但是业务还在写，两者并发以后就又卡...
前言安装12kubectl create namespace argocdkubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
自定义的配置自定义域名和instanceLabelKey如果使用helm的话，一般会用app.kubernetes.io/instance来当做标签, 而argocd默认也是用这个标签来追踪资源的，所以就会导致被重写导致部署的资源出错。
使用: application.instanceLabelKey...
前言目前主流的云商都支持服务器初始化的工具.
User Data格式一般 用户数据的格式为 两种.
Cloud Config Data 使用#cloud-config 或者 Content-Type: text/cloud-config 开头的
User-Data Script 使用#! 或者使用 Content-Type: text/x-shellscript 开头的
常用命令
cloud-init query userdata 查看 userdata
cloud-init status 查看状态
应用增加ssh_keys, 修改系统参数
12345678910111213141...
前言一个老生常谈的话题。 今天业务又遇到了，特此把情形分析一下，加深一次印象。
业务使用 Redis subscribe 订阅 channel, 分布在多地域多机房，通过内网的nginx代理，然后公网环境读取。
但是却经常发生断线的操作。但实际上，nginx并没有做过什么限制。 而且这2小时断一次很像是有些参数没有调对。
为了查清楚到底是谁发起的 rst, 从nginx和 应用两边抓包。但是并没有看到nginx这边出现rst。 应用这边也没有看到。
问题起初是有想到是因为 TCP keepalive 这个内核参数， 但是我们应用每30s都会去PING/PONG一下, 理论上是不会触发这...
前言使用CMD ["python", "/data/main.py"] 构建的镜像，代码中的print并没有在标准输出中。
查了一下，发现需要
需要使用无缓存输出才行
解决使用
1CMD ["python","-u","main.py"]
代替
1CMD ["python","main.py"]
前言复习一下
Annotationshttps://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/?spm=a2c4g.11186623.0.0.6d477557scGkgJ
序列化实例单对象序列化方式123from django.forms.models import model_to_dictdict_obj = model_to_dict(obj)
对象列表序列化方式123from django.core import serializersserialized_obj = serializers.serialize('json', [ obj, ])
前言暂时记录一下备份和恢复
备份二进制的方式备份123456#!/bin/bashdata_path=joplin_db-$(date +%Y-%m-%d).dmpexport PGPASSWORD="1231231"pg_dump -F c -f ${data_path} -C -E UTF8 -U joplin -h 127.0.0.1 -p 5432 joplin_db
恢复通过pg_restore恢复数据1pg_restore -c -U joplin -h 127.0.0.1 -p 5432 -d joplin_db joplin_db-202...
前言最近发现SSL错误, 点高级没有继续访问的选项。
问题最近chrome版本移除了关于ssl配置错误后，点高级没有继续访问的选项。提示如下：您的连接不是私密连接攻击者可能会试图从 x.x.x.x 窃取您的信息（例如：密码、通讯内容或信用卡信息）。了解详情NET::ERR_CERT_INVALID将您访问的部分网页的网址、有限的系统信息以及部分网页内容发送给 Google，以帮助我们提升 Chrome 的安全性。隐私权政策x.x.x.x 通常会使用加密技术来保护您的信息。Google Chrome 此次尝试连接到 x.x.x.x 时，此网站发回了异常的错误凭据。这可能是因为有攻击者在试图...
