<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[Ffffatass的博客]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/Ffffatass</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; Ffffatass]]></copyright><item><title><![CDATA[python并发相关]]></title><link>https://blog.youkuaiyun.com/Ffffatass/article/details/138901552</link><guid>https://blog.youkuaiyun.com/Ffffatass/article/details/138901552</guid><author>Ffffatass</author><pubDate>Wed, 15 May 2024 11:27:42 +0800</pubDate><description><![CDATA[同样，单进程在遇到CPU瓶颈时也需要使用多进程，进程的无状态也需要被保障。综上所述，进程是操作系统层面的独立执行单元，线程是操作系统调度的最小执行单位，而协程是由程序员控制调度的用户级执行单位。协程相较于进程和线程，具有更小的开销，并且能够实现非阻塞的协作式多任务。需要特别注意的是，python中的线程和Java中的线程是不同的。3、当循环中存在耗时操作，并且没有异步方式时，可以在循环中加入非阻塞休眠的代码。2、当某个方法不存在异步方法时，可以使用线程池执行耗时操作并等待线程执行结果。]]></description><category></category></item><item><title><![CDATA[并发场景下，mysql死锁和乐观锁异常]]></title><link>https://blog.youkuaiyun.com/Ffffatass/article/details/138901250</link><guid>https://blog.youkuaiyun.com/Ffffatass/article/details/138901250</guid><author>Ffffatass</author><pubDate>Wed, 15 May 2024 11:25:33 +0800</pubDate><description><![CDATA[但是回过头来，当务之急是解决加锁后依然存在乐观锁的问题，JPA的问题我们先放一放。仔细分析代码后我发现，虽然我给整个方法都加上了一个全局锁，让整个过程从并发变成了串行，并且也从日志中看到确实是串行的。既然我们自己的代码是一个查询语音，那可以大胆的猜测应该是JPA框架在执行这个findAll的代码行时执行了什么修改操作。根据其他产品研发的反馈，他们通过自动化上报菜单，所以是有并发场景的，于是为了可以重现bug，我先写了一个简单的测试程序，模拟并发的场景。我发现死锁的问题已经解决了，但是乐观锁的报错还是有。]]></description><category></category></item><item><title><![CDATA[RAG相关调研]]></title><link>https://blog.youkuaiyun.com/Ffffatass/article/details/133340293</link><guid>https://blog.youkuaiyun.com/Ffffatass/article/details/133340293</guid><author>Ffffatass</author><pubDate>Wed, 27 Sep 2023 09:39:50 +0800</pubDate><description><![CDATA[稀疏检索和稠密检索结合也是业界常用的一种办法，它在术语匹配方面就有很好的效果，很多向量数据库提供的查询方法本来就融合了这两种方式，但是其都有一个较为完整的处理逻辑。因此，为了生成答案，模型只考虑一个子问题的相关文档，而忽视了另一个子问题提出的问题。例如，在表6中，它错误地表示D组既是法国的世界杯分组，也是德国的世界杯分组，而事实上，德国实际上被分配到E组。当我们将检索到的上下文交给LLM时，模型本身在处理”噪音鲁棒性“，”负面拒绝“，”信息整合“，”反事实鲁棒性“四个方面存在一定的差异。]]></description><category></category></item><item><title><![CDATA[项目管理相关-落地方案]]></title><link>https://blog.youkuaiyun.com/Ffffatass/article/details/125482487</link><guid>https://blog.youkuaiyun.com/Ffffatass/article/details/125482487</guid><author>Ffffatass</author><pubDate>Mon, 27 Jun 2022 13:51:45 +0800</pubDate><description><![CDATA[方案评审（OARP 决策机制）+ 提高会议品质1、确认本次评审会议的四大角色，保证每个参会者拥有角色，并在会议通知中明确每位参会者的角色。负责人（Owner）：负责给出方案，组织各方讨论并推进做出最终的决定；批准者 （Approver)：最终批准者；审核者（Reviewer）：负责人和批准者挑选出的审核人。审核者有责任对文档进行讨论分析，并提出反馈意见，负责人必须重视并给予回复；参与者 （Participant）：其他提供意见的人。参与者会收到文档的相关信息，可以对相关问题做出反馈。2、※会议负责人需至少提]]></description><category></category></item><item><title><![CDATA[helm 版本不规范问题]]></title><link>https://blog.youkuaiyun.com/Ffffatass/article/details/123850185</link><guid>https://blog.youkuaiyun.com/Ffffatass/article/details/123850185</guid><author>Ffffatass</author><pubDate>Wed, 30 Mar 2022 16:38:32 +0800</pubDate><description><![CDATA[问题背景：最开始是发现使用3.2.x这个变量作为参数打包时，在jenkins打包完成后发现helm的chart包中依赖的subchart版本是3.2.1的。是之前打包的版本。
解决过程：
首先排查jenkins的配置，在添加了版本打印日志后，发现3.2.x这个版本确实是作为参数传入了。检查最外层的chart包中的Chart.yaml文件也可以看到版本是对的。
但是charts文件夹下的依赖却是3.2.1的。这就很奇怪了，这也是另一个同事之前看了很久没有问题。那也是从这个地方接手了这个工作。

我分析既然ch]]></description><category></category></item><item><title><![CDATA[prometheus调研注意事项]]></title><link>https://blog.youkuaiyun.com/Ffffatass/article/details/120787667</link><guid>https://blog.youkuaiyun.com/Ffffatass/article/details/120787667</guid><author>Ffffatass</author><pubDate>Fri, 15 Oct 2021 17:31:47 +0800</pubDate><description><![CDATA[云平台现有参数：每30秒抓取一次数据。数据留存10天。

1.几点原则

监控是基础设施，目的是为了解决问题，不要只朝着大而全去做，尤其是不必要的指标采集，浪费人力和存储资源。
需要处理的告警才发出来，发出来的告警必须得到处理。
简单的架构就是最好的架构，业务系统都挂了，监控也不能挂。

2.Prometheus 的局限

Prometheus 是基于 Metric 的监控，不适用于日志（Logs）、事件(Event)、调用链(Tracing)。
Prometheus 默认是 Pull 模型，合理规划你的网]]></description><category></category></item><item><title><![CDATA[解决容器僵尸进程]]></title><link>https://blog.youkuaiyun.com/Ffffatass/article/details/119329671</link><guid>https://blog.youkuaiyun.com/Ffffatass/article/details/119329671</guid><author>Ffffatass</author><pubDate>Mon, 02 Aug 2021 17:17:58 +0800</pubDate><description><![CDATA[在服务器上发现有大量的僵尸进程，通过进程号等信息发现是rancher中的rancher-agent容器中存在大量僵尸进程。


首先，进程号是一种资源，在宿主机中是有限的。存在大量僵尸进程的情况就可能会导致整个宿主机的进程号资源被全部占用，导致无法启动新的进程。


查看该容器的pids.max,发现其pid cgroups并没有限制，值为max。也就是该容器到最后会将进程号占用完，导致宿主机出现问题。


可以通过修改pids.max的方式，通过cgroup对其限制。但是显然这种情况是治标不治本的。那么，]]></description><category></category></item><item><title><![CDATA[k8s资源限制建议]]></title><link>https://blog.youkuaiyun.com/Ffffatass/article/details/119135268</link><guid>https://blog.youkuaiyun.com/Ffffatass/article/details/119135268</guid><author>Ffffatass</author><pubDate>Tue, 27 Jul 2021 09:53:37 +0800</pubDate><description><![CDATA[当应用限制了cpu和内存资源时，对于资源的配置建议如下：

1、cpu
requests为应用最小所需cpu，其值可以设置的相对小。只会将应用调度到满足该条件的节点。
limit为应用最大可使用cpu，其值可以设置得相对更大。提高应用峰值计算能力，如应用启动更快。
节点cpu资源争抢时，按照requests比例分配。
cpu为可压缩资源，出现资源不够的情况不会驱逐或重启应用。

示例：
resources: 
  requests:  
    cpu: 300m
 limits: ...]]></description><category></category></item></channel></rss>