图像检索服务器编写问题记录——日志系统问题记录

本文介绍了如何在星图GPU平台自动化部署实时手机检测-通用基于DAMO-YOLO和TinyNAS WebUI镜像，实现高效的手机目标检测。该镜像可广泛应用于移动端设备监控、图像内容审核等场景，通过自动化部署快速构建检测系统，提升识别效率与操作可追溯性。

本文介绍了如何在星图GPU平台上自动化部署👁️Qwen3-VL-4B Pro镜像，构建符合等保2.0要求的图文AI审计日志方案。该方案能将业务系统产生的操作截图等非结构化图像，自动转化为结构化、可检索的文本日志，典型应用于金融交易、政务审批等场景中的关键操作复核与异常行为发现，满足安全审计的合规性要求。

本文介绍了Chord视频时空理解工具的日志系统设计，重点阐述其故障排查与监控能力。用户可在星图GPU平台上自动化部署该镜像，快速搭建高效的视频分析环境。该工具的核心应用场景包括对视频内容进行时空理解分析，例如识别视频中的关键动作、事件与对象关系，为智能监控、内容审核等提供技术支持。

服务器端在选出匹配度高的图片后，将多个图片发送给客户端，结果客户端除了第一个图片正常外，其余都是乱码；运气好时，能有两个是正确的。打印客户端接收数据如下 136199 ��� ����l~,s8�[��:��<���zӓNjxn% �펿*% N��K��A�pGS�����[�`7�aC��������94H�&2�;��2�1��MS';f�J�6�4C��s�EHLȈLr

【1】SIFT特征没有自己编写，使用了opencv的SIFT特征提取、匹配函数。 【2】centos6.8装opencv3.0有问题，系统更换成了ubuntu14.04.4。opencv3已将sift库去掉，需要自己在git上下载编译，但是编译出来错误很多，诸多不顺，最终换成了老版本。opencv2.4.9，系统ubuntu14.04.4，很顺利。 【3】opencv特征库的描述子提取出来是c

上节在图片传输中，在主线程main中加入了epoll，结果和上上节的图片传输一结合，各种问题。 【问题】：将套接字设置成非阻塞，然后在epoll检测到sockfd有新数据时创建线程进行处理。然后问题来了，小图片第一次传输成功，第二次传输不成功；大图片一次传输都不成功；服务端图片size第一次打印正常 ，第二次打印乱码。 【解决步骤1】：于是将图片换成内容全是1和全是2的文本文件，来帮助检测。果

SIFT解决的问题及其思路 SIFT之前更加传统的匹配图像的方法是使用颜色、灰度等全局特征来描述整张图像，进而用这些全局特征去匹配图像。这样拍摄的光照、角度等因素对图像匹配的影响巨大。 解决的问题： 1.图像匹配时，两张相同图像，因为拍摄远近、模糊不同，导致匹配不出来。 2.图像匹配时，两张相同图像，因为拍摄角度、方向不同，导致匹配不出来。 3.图像匹配时，两张相同图像，

1.32bit系统，4G寻址空间，按线程栈10M来算（ulimit -a 查看stack size 默认为8192KB，即8M），系统最多支持400个线程。按原先的做法，将accept的套接字的缓冲区交由epoll监听，epoll监听到有数据之后，开新线程来处理。 这样做有个两个大问题： 【1】即使监听到了有新数据，由于新线程开不出来，还是没法处理数据，且因为EPOLLONESHOT的原因，再也没法收到读的信号，数据会一直卡在缓冲区中。 【2】图

任务队列底层容器的选择：          现在使用的是包装stl::queue后的自定义struct。std::queue可以使用deque（双端队列）作为底层容器（queue q）;也可以使用list作为底层容器(queue > q)。          若底层容器使用list，每个节点除任务信息外，均含一个指向下个节点的next指针索引。虽然相对于以deque为底层容器的队列，更能利用分

这个图像检索服务器在服务端的工作：1.接收客户端发来的图片+2.计算图片特征向量，匹配特征库图像+3.发回topK的相似图片。 上版的做法：一个eopll主线程循环检测是否有连接进来==》检测到连接，装填读任务队列==》读任务调度线程循环检测是否有读任务==》检测到读任务，分派工作线程去处理==》工作线程读完客户端发来的图片，装填计算图片片特征向量，匹配特征库图像队列===》计算队列调度

2.22思考：作为持有读写日志文件的指针的log类以及持有任务队列的server类，他们应该做成单例模式。

版本 版本简述 放弃理由 1 多进程：一个任务对应一个连接，一个连接对应一个进程。 所有进程都需与特征库中所有特征计算相似度。 特征库应共享，但多进程进程间共享困难。 2 多线程：一个任务对应一个连接，一个连接对应一个线程。 文件描述符太多，需要统一管理。 3 多线程：ep

1.用readn代替read的原因 为避免频繁的调用read。read调用系统调用，系统调用需要在用户态和核心态转换，需要保存上下文，频繁调用read，会使系统性能下降，in指标上升。为避免频繁调用read，我们在用户空间创建用户缓冲区，将套接字的缓冲区的内容全部读入用户缓冲区后，一次性把用户缓冲区的内容用read写入内核缓冲区。这样可以提高效率。相同的writen也是这个原因。 ss

【信号的分类】： 1.SIGKILL、SIGSTOP这两个信号单独一类，这两个信号不能被捕捉、忽略和阻塞。表示杀死进程和暂停进程，它们为root提供了一种一定可以杀死或暂停进程的方法。 2.SIGBUS、SIGFPE、SIGSEGV这类由硬件引起的硬件故障、段错误、除0错误等信号只会发送给引起该硬件错误的线程。 3.SIGCHLD、SIGALRM、SIGUSR1等等普通信号 【信号

今早将原先sever的纯c代码，改写成C++类，一运行，昨天好好的，改完之后就跑不起来了。于是查啊查，查了一早上，最终定位到LOG的MUTEX这边。 非常奇怪的是当我在MUTEX的构造，析构函数中加入fprintf打印输出时，serv运行正常，但当我将fprintf注释掉后，serv就卡在那儿，下不去了。 百试百灵，这还能忍？！！！谁干的坏事儿？，于是我将makefile中的-O2，编

0.服务器端模型选择 大体思路是：在主线程中使用epoll承受高并发连接，在主线程中开辟工作线程用来处理就绪的描述符。嗯，这个原来有官名，叫反应者模式。事件驱动编程。另外工作线程处理的就绪的文件描述符最好是非阻塞的。