memcached的线程模型
Memcached数据结构 memcached的多线程主要是通过实例化多个libevent实现的,分别是一个主线程和n个workers线程。每个线程都是一个单独的libevent实例,主线程eventloop负责处理监听fd,监听客户端的建立连接请求,以及accept连接,将已建立的连接round robin到
Memcached数据结构
memcached的多线程主要是通过实例化多个libevent实现的,分别是一个主线程和n个workers线程。每个线程都是一个单独的libevent实例,主线程eventloop负责处理监听fd,监听客户端的建立连接请求,以及accept连接,将已建立的连接round robin到各个worker。workers线程负责处理已经建立好的连接的读写等事件。”one event loop per thread”.
首先看下主要的数据结构
thread.c
CQ_ITEM是主线程accept后返回的已建立连接的fd的封装。
/* An item in the connection queue. */ typedef struct conn_queue_item CQ_ITEM; struct conn_queue_item { int sfd; int init_state; int event_flags; int read_buffer_size; int is_udp; CQ_ITEM *next; };
CQ是一个管理CQ_ITEM的单向链表
/* A connection queue. */ typedef struct conn_queue CQ; struct conn_queue { CQ_ITEM *head; CQ_ITEM *tail; pthread_mutex_t lock; pthread_cond_t cond; };
LIBEVENT_THREAD 是memcached里的线程结构的封装,可以看到每个线程都包含一个CQ队列,一条通知管道pipe和一个libevent的实例event_base。
typedef struct { pthread_t thread_id; /* unique ID of this thread */ struct event_base *base; /* libevent handle this thread uses */ struct event notify_event; /* listen event for notify pipe */ int notify_receive_fd; /* receiving end of notify pipe */ int notify_send_fd; /* sending end of notify pipe */ CQ new_conn_queue; /* queue of new connections to handle */ } LIBEVENT_THREAD;
Memcached对每个网络连接的封装conn
typedef struct{ int sfd; int state; struct event event; short which; char *rbuf; ... //这里省去了很多状态标志和读写buf信息等 }conn;
memcached主要通过设置/转换连接的不同状态,来处理事件(核心函数是drive_machine,连接的状态机)。
Memcached线程处理流程
Memcached.c
里main函数,先对主线程的libevent实例进行初始化, 然后初始化所有的workers线程,并启动。接着主线程调用server_socket(这里只分析tcp的情况)创建监听socket,绑定地址,设置非阻塞模式并注册监听socket的libevent 读事件等一系列操作。最后主线程调用event_base_loop接收外来连接请求。
Main() { /* initialize main thread libevent instance */ main_base = event_init(); /* start up worker threads if MT mode */ thread_init(settings.num_threads, main_base); server_socket(settings.port, 0); /* enter the event loop */ event_base_loop(main_base, 0); }
最后看看memcached网络事件处理的最核心部分- drive_machine drive_machine是多线程环境执行的,主线程和workers都会执行drive_machine。
static void drive_machine(conn *c) { bool stop = false; int sfd, flags = 1; socklen_t addrlen; struct sockaddr_storage addr; int res; assert(c != NULL); while (!stop) { switch(c->state) { case conn_listening: addrlen = sizeof(addr); if ((sfd = accept(c->sfd, (struct sockaddr *)&addr, &addrlen)) == -1) { //省去n多错误情况处理 break; } if ((flags = fcntl(sfd, F_GETFL, 0)) <p>drive_machine主要是通过当前连接的state来判断该进行何种处理,因为通过libevent注册了读写事件后回调的都是这个核心函数,所以实际上我们在注册libevent相应事件时,会同时把事件状态写到该conn结构体里,libevent进行回调时会把该conn结构作为参数传递过来,就是该方法的形参。 连接的状态枚举如下。</p> <p class="highlight"></p><pre class="brush:php;toolbar:false"> enum conn_states { conn_listening, /** the socket which listens for connections */ conn_read, /** reading in a command line */ conn_write, /** writing out a simple response */ conn_nread, /** reading in a fixed number of bytes */ conn_swallow, /** swallowing unnecessary bytes w/o storing */ conn_closing, /** closing this connection */ conn_mwrite, /** writing out many items sequentially */ };
实际对于case conn_listening:这种情况是主线程自己处理的,workers线程永远不会执行此分支我们看到主线程进行了accept后调用了
dispatch_conn_new(sfd, conn_read, EV_READ | EV_PERSIST,DATA_BUFFER_SIZE, false);
这个函数就是通知workers线程的地方,看看
void dispatch_conn_new(int sfd, int init_state, int event_flags, int read_buffer_size, int is_udp) { CQ_ITEM *item = cqi_new(); int thread = (last_thread + 1) % settings.num_threads; last_thread = thread; item->sfd = sfd; item->init_state = init_state; item->event_flags = event_flags; item->read_buffer_size = read_buffer_size; item->is_udp = is_udp; cq_push(&threads[thread].new_conn_queue, item); MEMCACHED_CONN_DISPATCH(sfd, threads[thread].thread_id); if (write(threads[thread].notify_send_fd, "", 1) != 1) { perror("Writing to thread notify pipe"); } }
可以清楚的看到,主线程首先创建了一个新的CQ_ITEM,然后通过round robin策略选择了一个thread并通过cq_push将这个CQ_ITEM放入了该线程的CQ队列里,那么对应的workers线程是怎么知道的呢? 就是通过
write(threads[thread].notify_send_fd, "", 1)
向该线程管道写了1字节数据,则该线程的libevent立即回调了thread_libevent_process方法(上面已经描述过)。 然后那个线程取出item,注册读时间,当该条连接上有数据时,最终也会回调drive_machine方法,也就是drive_machine方法的 case conn_read:等全部是workers处理的,主线程只处理conn_listening 建立连接这个。 memcached的这套多线程event机制很值得设计linux后端网络程序时参考。
参考文献
- memcache源码分析--线程模型
- memcached结构分析——线程模型
- Memcached的线程模型及状态机
原文地址:memcached的线程模型, 感谢原作者分享。

핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

AI Hentai Generator
AI Hentai를 무료로 생성하십시오.

인기 기사

뜨거운 도구

메모장++7.3.1
사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기
강력한 PHP 통합 개발 환경

드림위버 CS6
시각적 웹 개발 도구

SublimeText3 Mac 버전
신 수준의 코드 편집 소프트웨어(SublimeText3)

뜨거운 주제











기존 컴퓨팅을 능가할 뿐만 아니라 더 낮은 비용으로 더 효율적인 성능을 달성하는 인공 지능 모델을 상상해 보세요. 이것은 공상과학 소설이 아닙니다. DeepSeek-V2[1], 세계에서 가장 강력한 오픈 소스 MoE 모델이 여기에 있습니다. DeepSeek-V2는 경제적인 훈련과 효율적인 추론이라는 특징을 지닌 전문가(MoE) 언어 모델의 강력한 혼합입니다. 이는 236B 매개변수로 구성되며, 그 중 21B는 각 마커를 활성화하는 데 사용됩니다. DeepSeek67B와 비교하여 DeepSeek-V2는 더 강력한 성능을 제공하는 동시에 훈련 비용을 42.5% 절감하고 KV 캐시를 93.3% 줄이며 최대 생성 처리량을 5.76배로 늘립니다. DeepSeek은 일반 인공지능을 연구하는 회사입니다.

이달 초 MIT와 기타 기관의 연구자들은 MLP에 대한 매우 유망한 대안인 KAN을 제안했습니다. KAN은 정확성과 해석성 측면에서 MLP보다 뛰어납니다. 그리고 매우 적은 수의 매개변수로 더 많은 수의 매개변수를 사용하여 실행되는 MLP보다 성능이 뛰어날 수 있습니다. 예를 들어 저자는 KAN을 사용하여 더 작은 네트워크와 더 높은 수준의 자동화로 DeepMind의 결과를 재현했다고 밝혔습니다. 구체적으로 DeepMind의 MLP에는 약 300,000개의 매개변수가 있는 반면 KAN에는 약 200개의 매개변수만 있습니다. KAN은 MLP와 같이 강력한 수학적 기반을 가지고 있으며, KAN은 Kolmogorov-Arnold 표현 정리를 기반으로 합니다. 아래 그림과 같이 KAN은

테슬라의 로봇 옵티머스(Optimus)의 최신 영상이 공개됐는데, 이미 공장에서 작동이 가능한 상태다. 정상 속도에서는 배터리(테슬라의 4680 배터리)를 다음과 같이 분류합니다. 공식은 또한 20배 속도로 보이는 모습을 공개했습니다. 작은 "워크스테이션"에서 따고 따고 따고 : 이번에 출시됩니다. 영상에는 옵티머스가 공장에서 이 작업을 전 과정에 걸쳐 사람의 개입 없이 완전히 자율적으로 완료하는 모습이 담겨 있습니다. 그리고 Optimus의 관점에서 보면 자동 오류 수정에 중점을 두고 구부러진 배터리를 집어 넣을 수도 있습니다. NVIDIA 과학자 Jim Fan은 Optimus의 손에 대해 높은 평가를 했습니다. Optimus의 손은 세계의 다섯 손가락 로봇 중 하나입니다. 가장 능숙합니다. 손은 촉각적일 뿐만 아니라

1. 소개 지난 몇 년 동안 YOLO는 계산 비용과 감지 성능 간의 효과적인 균형으로 인해 실시간 객체 감지 분야에서 지배적인 패러다임이 되었습니다. 연구원들은 YOLO의 아키텍처 설계, 최적화 목표, 데이터 확장 전략 등을 탐색하여 상당한 진전을 이루었습니다. 동시에 사후 처리를 위해 NMS(비최대 억제)에 의존하면 YOLO의 엔드투엔드 배포가 방해되고 추론 대기 시간에 부정적인 영향을 미칩니다. YOLO에서는 다양한 구성 요소의 설계에 포괄적이고 철저한 검사가 부족하여 상당한 계산 중복이 발생하고 모델 기능이 제한됩니다. 이는 최적이 아닌 효율성을 제공하며 성능 향상을 위한 상대적으로 큰 잠재력을 제공합니다. 이 작업의 목표는 사후 처리와 모델 아키텍처 모두에서 YOLO의 성능 효율성 경계를 더욱 향상시키는 것입니다. 이를 위해

FP8 이하의 부동 소수점 수량화 정밀도는 더 이상 H100의 "특허"가 아닙니다! Lao Huang은 모든 사람이 INT8/INT4를 사용하기를 원했고 Microsoft DeepSpeed 팀은 NVIDIA의 공식 지원 없이 A100에서 FP6을 실행하기 시작했습니다. 테스트 결과에 따르면 A100에 대한 새로운 방법 TC-FPx의 FP6 양자화는 INT4에 가깝거나 때로는 더 빠르며 후자보다 정확도가 더 높은 것으로 나타났습니다. 또한 오픈 소스로 제공되고 DeepSpeed와 같은 딥 러닝 추론 프레임워크에 통합된 엔드투엔드 대규모 모델 지원도 있습니다. 이 결과는 대형 모델 가속화에도 즉각적인 영향을 미칩니다. 이 프레임워크에서는 단일 카드를 사용하여 Llama를 실행하면 처리량이 듀얼 카드보다 2.65배 더 높습니다. 하나

소프트웨어 기술의 선두에 있는 UIUC Zhang Lingming 그룹은 BigCode 조직의 연구원들과 함께 최근 StarCoder2-15B-Instruct 대규모 코드 모델을 발표했습니다. 이 혁신적인 성과는 코드 생성 작업에서 획기적인 발전을 이루었으며 CodeLlama-70B-Instruct를 성공적으로 능가하고 코드 생성 성능 목록의 최상위에 올랐습니다. StarCoder2-15B-Instruct의 독창성은 순수한 자체 정렬 전략에 있습니다. 전체 훈련 프로세스는 개방적이고 투명하며 완전히 자율적이고 제어 가능합니다. 이 모델은 값비싼 수동 주석에 의존하지 않고 StarCoder-15B 기본 모델을 미세 조정한 것에 대한 응답으로 StarCoder2-15B를 통해 수천 개의 명령을 생성합니다.

대규모 언어 모델(LLM)을 인간의 가치와 의도에 맞추려면 인간의 피드백을 학습하여 유용하고 정직하며 무해한지 확인하는 것이 중요합니다. LLM 정렬 측면에서 효과적인 방법은 인간 피드백 기반 강화 학습(RLHF)입니다. RLHF 방법의 결과는 훌륭하지만 몇 가지 최적화 문제가 있습니다. 여기에는 보상 모델을 훈련한 다음 해당 보상을 극대화하기 위해 정책 모델을 최적화하는 것이 포함됩니다. 최근 일부 연구자들은 더 간단한 오프라인 알고리즘을 탐구했는데, 그 중 하나가 직접 선호 최적화(DPO)입니다. DPO는 RLHF의 보상 기능을 매개변수화하여 선호도 데이터를 기반으로 직접 정책 모델을 학습하므로 명시적인 보상 모델이 필요하지 않습니다. 이 방법은 간단하고 안정적입니다.

표적 탐지 시스템의 벤치마크 YOLO 시리즈가 다시 한 번 대대적인 업그레이드를 받았습니다. 올해 2월 YOLOv9이 출시된 이후 YOLO(YouOnlyLookOnce) 시리즈의 지휘봉은 칭화대학교 연구진의 손에 넘어갔다. 지난 주말 YOLOv10 출시 소식이 AI 커뮤니티의 관심을 끌었다. 컴퓨터 비전 분야의 획기적인 프레임워크로 간주되며 실시간 엔드투엔드 개체 감지 기능으로 유명하며 효율성과 정확성을 결합한 강력한 솔루션을 제공함으로써 YOLO 시리즈의 유산을 이어갑니다. 논문 주소: https://arxiv.org/pdf/2405.14458 프로젝트 주소: https://github.com/THU-MIG/yo
