qq_42896627的博客

结合堆栈一起看，看上去像是发送端通过unicenter发送大数据包给其他模块，可能是数据比较大，发的有点慢，导致进程的固定回调线程都被占满了，全部都是send_packet，这个时候仍然有其他模块来通过unicenter发送数据导致返回超时，但是我们该做的优化措施都做了。这个时候我们只能在看下网络延迟的情况，抽取几个sendq值较大的连接，ping了下，发现发送64bytes的数据，延迟最多达到了500ms，原来是这些机器和unicenter所在的机器之间延迟太大导致的超时。抓包也验证了网络延迟高的问题。

以上接着查看发送端的网络问题发现延迟这些都正常，并且发送端使用syslog udp发送也是没问题的，所以判断为接收端问题，接收端处理太慢导致的，如此答复web同事后。web端最后排查是他们自身的问题。原话是：“不是，有问题的这种我是通过syslog提供的包搞的，之前没问题的用的apache的包搞的”。sendq（发送队列）和recvq（接收队列）是系统级别的队列，而非特定于某个程序的队列。web同事开发了一个用于接收syslog数据的服务器，不清楚web的开发方式，用来联调的发送端是我们的C模块。

【代码】kylinx86编译libodbc.a。

如果消息长度是64k以内，不需要开发人员在应用层分片，发送不会失败，但是单次最大长度是1500-头部，大概1400多，也就是会分片传多次，接收端会自行会重组数据的，但不会校验，如果在传输过程中有数据包丢失或损坏，接收端可能无法重组出完整的数据。所以：udp发送超过64k(大概的数字，除去ip和udp头部长度)，需要开发人员在应用层把消息分片，不然系统的发送接口sendto会报错（message too long），返回-1，发送失败，接收端收不到任何消息。接收端开启的是linux自带的rsyslog服务。

发送端的生产者是轮询的发送机制发送数据，客户的kafka服务器的某个topic有三个分区，客户反馈只有一个分区收到数据，其他分区没有，客户质疑是我们的轮询机制有问题。所以我要求客户重建了新的topic，也是三个分区，这个时候接收却正常了，三个分区都可接收数据也确实是按照轮询的方式接收到的。往客户提供的kafka服务器上的一个topic发送数据，这个topic有三个分区，客户反馈接收到的数据和发送端发送的实际数量对不上，他们只有一个分区接收到了数据，其他两个分区没有接收到。联调抓包发现一切正常。

在PG中事务年龄不能超过2^31 （2的31次方=2,147,483,648），如果超过了，这条数据就会丢失。PG中不允许这种情况出现，当事务的年龄离2^31还有1千万的时候，数据库的日志中就会有如下告警：如果不处理，当事务的年龄离2^31还有1百万时，数据库服务器出于安全考虑，将会自动禁止任何来自任何用户的连接，同时在日志中是如下信息：(某个现场服务器的pg日志截图)然后我们去查看这个表的事务id。

而后修改makefile添加-Wl,–exclude-libs,ALL后才隐藏了libblowsnow_db.a里面所有的符号，重新编译UniAuditToSysLog替换后验证，发现模块可正常运行。提供一个centos的gdb包 gdb-7.6.1-120.el7.x86_64。执行rpm -ivh gdb-7.6.1-120.el7.x86_64 安装失败。重新执行rpm -ivh gdb-7.6.1-120.el7.x86_64。手动运行模块后，设置的路径下生成了core文件。

1 排查用到了linux的监控服务 audit配置规则自行百度 发现我们的模块修改odbc.ini文件。2 排查了自己服务和链接的静态库的所有代码没有操作odbc.ini的代码，转而怀疑系统的odbc库。下载相应版本代码查看关键字 “odbc.ini” 发现了此处的代码。unixodbc官网地址–> https://www.unixodbc.org/现象：某个现场 odbc.ini 莫名其妙被清空，偶发情况，大概几周出现一次。对比下不同版本的代码还是很明显的能看出问题所在。

某个客户现场部署的数据库是Oracle的，历史遗留原因，Oracle密码在配置文件里是明文的，客户要求修改为密文，修改后交由客户验证，客户反馈修改密码后，终端上报审计信息插入Oracle时，模块崩溃了，按理说密码即使不对或者解析问题也不会崩溃。不需要看实现细节，也能看出来根据’/’ '@'符号去切割的，当然官网也提供了更多的重载的接口(rlogon)，并非一定要使用这种格式的接口，但是这种接口是更通用的，对于连接不同类型的数据库来说。rlogon()这个封装在最底层的接口是otl提供的，查看官网接口文档。

某天，一银行客户反馈，我们的数据传输模块发送过去的数据，他们接收到解析出来的乱码，问我们发送的数据到底是不是utf8

系统日志/var/log/message，搜索模块的名字，发现了。通过这个inode，去查看我们日志文件的inode对比是相同的。

3 官网文档给的例子，select这里没有设置set_commit(0)，但是insert是有设置的，如果没有设置，程序运行会报错的，如下图。我们内部有封装代码，不过也是根据官网文档来的，链接：http://otl.sourceforge.net/otl3_ex128.htm。因为业务需求，web方面将字段text修改为mediumtext，同时也需要server方面来适配。4 此外还需注意的点，无论text/mediumtext/longtext类型的都需要将该字段放在语句的最后。............

静态库覆盖动态库同名类以及方法

现场使用的postgre版本忘记查了，但是不影响，只需要知道postgre有些版本大小写是不敏感的就行关于大小写不敏感1、创建视图语句CREATE OR REPLACE VIEW public.v_approval_results ASselecta.uidRecordID “uidRecordID”,a.uidApplyID “uidApplyID”,b.strUserName “strUserName”,b.strUserDesc “strUserDesc”,b.uiddeptid “

现场问题排查记录：现场反映的问题，每天早上会有部分用户正常认证成功，但是第三方无上线信息，导致无法访问外网，日志排查发现有个模块没有将登录信息发送到后台现场服务是主备模式的。后台的服务有一个模块是用来转发数据库通知给其他模块的。现在我们去查看负责转发模块的日志发现备机的转发模块每隔四小时和主机的其他模块断开连接一次，每次持续几分钟，几分钟后重新建立连接，在断开连接的时间点如早上9点，部分用户认证成功，但是这时候断开连接了，转发模块没有将信息发出去通知其他模块。怀疑是网络问题，让现场同事在断开连接的时间点

STL glibc list的size方法所以仅仅是判断list容器是否有元素存在应该使用empty而不是list，避免进入复杂度为O(N）的重载函数中导致入坑bool empty() const { return _M_node->_M_next == _M_node; } size_type size() const { size_type __result = 0; distance(begin(), end(), __result); return __res

上一篇文章中，我们使用gdb抓取堆栈分析了server运行，得出了结论。在某处抢占到读锁(对于共享资源map容器的保护，map的key为设备id，value为该设备的相关信息)时，获取设备相关信息，去进行过滤判断然后进行非常耗时的策略计算等操作，导致了其他线程在获取读锁或写锁时一直处于等待状态无法处理业务。并且总的来说是一个多读少写(相对少写)的情况。当前项目的处理 伪代码void dealtask(){ //并且这个读锁粒度太大了，当然还有其它业务也需要使用这个map，但并不是很费事的操作。不

反馈后台Server运行卡住，结合以往可能是死锁了或者某个锁已经被抢占了但是在进行某些操作时费时很久，导致其他锁一致在等待。gdb抓到的堆栈如下。大致浏览了一下，做了个分类：14 15 103 set_new_agent_msg_state —>重复的线程栈21-28 35 36 61 dec_agent_pushing_count —>重复的线程栈21 52 53 55 56 58-60 68-82 106-110 112 recv_agent_online —>重复的

上周有新任务开发，然后周五开发完了，和其他同事联调(不能远程调试)，发现客户端上报给server之后，serever莫名其妙的就挂了，然后被重新启动(重启是自己设置的，只要进程不存在就回去启动程序)，只要上报了新增的功能相关的，server就会挂掉，上报原来有的都是正常的。但是并不是被kill掉了，也不是崩溃了。因为程序里收到SIGSEGV和SIGABRT会打印堆栈信息到一个文件里面。但是没有发现有这个文件生成。后面给了一个抓堆栈的脚本，然后那边同事抓给我的结果是文件为空。我以为没抓到，然后看了下日志，s

IDA Free: https://hex-rays.com/ida-free/#download客户反馈的日志，可以看到FROM tbl_ud_pe_eventreport_network_sum limit 0 offset 1188 part F436B5F1BCEA75FB204A64C83EF4C90D7执行语句报错了。[1597725][2021-08-18][12:03:35][T1096963840][HQueryDB.cpp ][0303][I]query_acuta_