हाल ही में, मतदान के लिए एक नए कर्नेल इंटरफ़ेस के बारे में लेखक का ध्यान LWN के एक लेख की ओर आकर्षित हुआ। यह लिनक्स एआईओ एपीआई (अतुल्यकालिक फ़ाइल हैंडलिंग के लिए एक इंटरफ़ेस) में नए मतदान तंत्र पर चर्चा करता है, जिसे कर्नेल संस्करण 4.18 में जोड़ा गया था। यह विचार काफी दिलचस्प है: पैच का लेखक नेटवर्क के साथ काम करने के लिए लिनक्स एआईओ एपीआई का उपयोग करने का सुझाव देता है।

लेकिन एक पल रुकिए! आखिर, डिस्क से डिस्क पर एसिंक्रोनस I / O के साथ काम करने के लिए Linux AIO बनाया गया था! डिस्क पर फ़ाइलें नेटवर्क कनेक्शन के समान नहीं हैं। क्या नेटवर्किंग के लिए लिनक्स एआईओ एपीआई का उपयोग करना भी संभव है?

यह हाँ निकलता है, यह संभव है! यह आलेख बताता है कि कैसे तेजी से और बेहतर नेटवर्क सर्वर बनाने के लिए लिनक्स एआईओ एपीआई की ताकत का उपयोग करना है।

लेकिन आइए लिनक्स एआईओ क्या है, यह बताकर शुरू करें।

लिनक्स एआईओ का परिचय

लिनक्स एआईओ उपयोगकर्ता सॉफ्टवेयर के लिए एसिंक्रोनस डिस्क-टू-डिस्क I / O प्रदान करता है।

ऐतिहासिक रूप से, लिनक्स पर, सभी डिस्क संचालन अवरुद्ध थे। यदि आप open() , read() , write() या fsync() , तो स्ट्रीम तब तक बंद हो जाती है जब तक कि मेटाडाटा डिस्क कैश में प्रकट नहीं हो जाता है। यह आमतौर पर कोई समस्या नहीं है। यदि आपके पास कई आई / ओ संचालन और पर्याप्त मेमोरी नहीं है, तो सिस्टम कॉल धीरे-धीरे कैश को भर देंगे, और सब कुछ जल्दी से पर्याप्त काम करेगा।

I / O संचालन का प्रदर्शन कम हो जाता है जब उनकी संख्या पर्याप्त होती है, उदाहरण के लिए, डेटाबेस और प्रॉक्सी के मामलों में। ऐसे अनुप्रयोगों के लिए, एक read() सिस्टम कॉल की प्रतीक्षा करने के लिए पूरी प्रक्रिया को रोकना अस्वीकार्य है।

इस समस्या को हल करने के लिए, अनुप्रयोग तीन विधियों का उपयोग कर सकते हैं:

थ्रेड पूल का उपयोग करें और अलग थ्रेड्स पर अवरुद्ध कार्यों को कॉल करें। यह कैसे POSIX AIO glibc में काम करता है (लिनक्स AIO के साथ इसे भ्रमित न करें)। अधिक जानकारी के लिए, आईबीएम प्रलेखन देखें। इस तरह हमने क्लाउडफ़ेयर में समस्या हल की: हम थ्रेड पूल का उपयोग read() और open() कॉल करने के लिए करते read() ।
posix_fadvise(2) साथ डिस्क कैश को गर्म करें और सर्वश्रेष्ठ के लिए आशा करें।
XFS फ़ाइल सिस्टम के साथ Linux AIO का उपयोग करें, O_DIRECT फ़्लैग के साथ फाइलें खोलना और अनचाही समस्याओं से बचना ।

हालाँकि, इनमें से कोई भी तरीका आदर्श नहीं है। यहां तक कि लिनक्स io_submit() , जब बिना सोचे समझे उपयोग किया जाता है, तो io_submit() कॉल में अवरुद्ध किया जा सकता है। हाल ही में LWN के एक अन्य लेख में इसका उल्लेख किया गया है:

"लिनक्स अतुल्यकालिक I / O इंटरफ़ेस में बहुत सारे आलोचक और कुछ समर्थक हैं, लेकिन अधिकांश लोग इससे कम से कम अतुल्यकालिकता की उम्मीद करते हैं। वास्तव में, AIO ऑपरेशन उन स्थितियों में कई कारणों से कर्नेल में अवरुद्ध हो सकता है जहां कॉलिंग थ्रेड इसे बर्दाश्त नहीं कर सकता है। ”

अब जब हम लिनक्स AIO API की कमजोरियों को जानते हैं, तो आइए इसकी खूबियों पर नजर डालते हैं।

लिनक्स AIO का उपयोग कर एक सरल कार्यक्रम

लिनक्स एआईओ का उपयोग करने के लिए, आपको पहले सभी पांच आवश्यक सिस्टम कॉल को स्वयं निर्धारित करना होगा - ग्लिब्क उन्हें प्रदान नहीं करता है।

पहले आपको aio_context संरचना को इनिशियलाइज़ करने के लिए io_setup() को कॉल करना होगा। कर्नेल संरचना में एक अपारदर्शी सूचक लौटाएगा।
उसके बाद, आप io_submit() को "I / O नियंत्रण खंड" के वेक्टर को एक संरचना iocb संरचना के रूप में प्रसंस्करण कतार में जोड़ने के लिए कह सकते हैं।
अब, आखिरकार, हम io_getevents() को कॉल कर सकते हैं और इसके लिए एक उत्तर की प्रतीक्षा कर सकते हैं सदिश io_event संरचनाओं के वेक्टर के रूप में - प्रत्येक iocb ब्लॉकों के परिणाम।

आठ आज्ञाएँ हैं जो आप iocb में उपयोग कर सकते हैं। पढ़ने के लिए दो कमांड, लिखने के लिए दो, दो fsync विकल्प, और POLL कमांड, जो कर्नेल संस्करण 4.18 में जोड़ा गया था (आठवां कमांड NOOP है):

 IOCB_CMD_PREAD = 0, IOCB_CMD_PWRITE = 1, IOCB_CMD_FSYNC = 2, IOCB_CMD_FDSYNC = 3, IOCB_CMD_POLL = 5,   /* from 4.18 */ IOCB_CMD_NOOP = 6, IOCB_CMD_PREADV = 7, IOCB_CMD_PWRITEV = 8,

iocb , जिसे io_submit फ़ंक्शन से पारित किया गया है, काफी बड़ी है और डिस्क के साथ काम करने के लिए डिज़ाइन की गई है। यहाँ इसका सरलीकृत संस्करण है:

 struct iocb { __u64 data;           /* user data */ ... __u16 aio_lio_opcode; /* see IOCB_CMD_ above */ ... __u32 aio_fildes;     /* file descriptor */ __u64 aio_buf;        /* pointer to buffer */ __u64 aio_nbytes;     /* buffer size */ ... }

पूर्ण io_event संरचना जो io_getevents देता है:

 struct io_event { __u64  data; /* user data */ __u64  obj; /* pointer to request iocb */ __s64  res; /* result code for this event */ __s64  res2; /* secondary result */ };

एक उदाहरण है। एक सरल प्रोग्राम जो लिनक्स AIO API का उपयोग करके / etc / passwd फ़ाइल पढ़ता है:

 fd = open("/etc/passwd", O_RDONLY); aio_context_t ctx = 0; r = io_setup(128, &ctx); char buf[4096]; struct iocb cb = {.aio_fildes = fd,                 .aio_lio_opcode = IOCB_CMD_PREAD,                 .aio_buf = (uint64_t)buf,                 .aio_nbytes = sizeof(buf)}; struct iocb *list_of_iocb[1] = {&cb}; r = io_submit(ctx, 1, list_of_iocb); struct io_event events[1] = {{0}}; r = io_getevents(ctx, 1, 1, events, NULL); bytes_read = events[0].res; printf("read %lld bytes from /etc/passwd\n", bytes_read);

पूर्ण स्रोत निश्चित रूप से, GitHub पर उपलब्ध हैं । यहाँ इस कार्यक्रम की धारा उत्पादन है:

 openat(AT_FDCWD, "/etc/passwd", O_RDONLY) io_setup(128, [0x7f4fd60ea000]) io_submit(0x7f4fd60ea000, 1, [{aio_lio_opcode=IOCB_CMD_PREAD, aio_fildes=3, aio_buf=0x7ffc5ff703d0, aio_nbytes=4096, aio_offset=0}]) io_getevents(0x7f4fd60ea000, 1, 1, [{data=0, obj=0x7ffc5ff70390, res=2494, res2=0}], NULL)

सब कुछ ठीक चला, लेकिन डिस्क से पढ़ना अतुल्यकालिक नहीं था: io_submit कॉल को अवरुद्ध कर दिया गया था और सभी काम किया था, io_getevents फ़ंक्शन io_getevents तुरंत निष्पादित किया io_getevents । हम अतुल्यकालिक रूप से पढ़ने की कोशिश कर सकते हैं, लेकिन इसके लिए O_DIRECT ध्वज की आवश्यकता होती है, जिसके साथ डिस्क संचालन कैश को बायपास करता है।

आइए बेहतर बताते हैं कि कैसे io_submit नियमित फ़ाइलों पर लॉक करता है। यहाँ एक समान उदाहरण है जो 1 GB ब्लॉक को /dev/zero से पढ़ने के परिणामस्वरूप स्ट्रेस का आउटपुट दिखाता /dev/zero :

 io_submit(0x7fe1e800a000, 1, [{aio_lio_opcode=IOCB_CMD_PREAD, aio_fildes=3, aio_buf=0x7fe1a79f4000, aio_nbytes=1073741824, aio_offset=0}]) \   = 1 <0.738380> io_getevents(0x7fe1e800a000, 1, 1, [{data=0, obj=0x7fffb9588910, res=1073741824, res2=0}], NULL) \   = 1 <0.000015>

कर्नेल ने io_submit कॉल पर 738 ms खर्च किए io_submit और io_getevents पर केवल 15 ns। यह नेटवर्क कनेक्शन के साथ समान व्यवहार करता है - सभी काम io_submit द्वारा किया जाता है।

फोटो हेलिक्स84 सीसी / बाय-एसए / 3.0

लिनक्स AIO और नेटवर्क

io_submit कार्यान्वयन काफी रूढ़िवादी है: यदि उत्तीर्ण फ़ाइल डिस्क्रिप्टर को O_DIRECT ध्वज के साथ नहीं खोला गया था, तो फ़ंक्शन बस ब्लॉक करता है और निर्दिष्ट कार्रवाई करता है। नेटवर्क कनेक्शन के मामले में, इसका मतलब है कि:

अवरुद्ध कनेक्शन के लिए, IOCV_CMD_PREAD प्रतिक्रिया पैकेट की प्रतीक्षा करेगा;
गैर-अवरुद्ध कनेक्शन के लिए, IOCB_CMD_PREAD कोड -11 (EAGAIN) लौटाएगा।

समान शब्दार्थ का उपयोग नियमित read() सिस्टम कॉल में भी किया जाता है, इसलिए हम कह सकते हैं कि नेटवर्क कनेक्शन के साथ काम करते समय io_submit अच्छे पुराने read() / write() कॉल से अधिक स्मार्ट नहीं होता है।

यह ध्यान रखना महत्वपूर्ण है कि iocb अनुरोध कर्नेल द्वारा क्रमिक रूप से निष्पादित किए iocb ।

इस तथ्य के बावजूद कि लिनक्स एआईओ हमें अतुल्यकालिक संचालन में मदद नहीं करेगा, इसका उपयोग सिस्टम कॉल को बैचों में संयोजित करने के लिए किया जा सकता है।

यदि वेब सर्वर को सैकड़ों नेटवर्क कनेक्शन से डेटा भेजने और प्राप्त करने की आवश्यकता है, तो io_submit का उपयोग io_submit एक महान विचार हो सकता है, क्योंकि यह सैकड़ों भेजने और पुन: कॉल करने से बचता है। यह प्रदर्शन में सुधार करेगा - उपयोगकर्ता की जगह से कर्नेल पर स्विच करना और इसके विपरीत मुक्त नहीं है, खासकर स्पेक्ट्रम और मेल्टडाउन से निपटने के उपायों की शुरूआत के बाद।

	एक बफर	एकाधिक बफ़र्स
एक फाइल डिस्क्रिप्टर	पढ़ें ()	रीडव ()
मल्टीपल फाइल डिस्क्रिप्टर्स	io_submit + IOCB_CMD_PREAD	io_submit + IOCB_CMD_PREADV

io_submit का उपयोग करते हुए पैकेटों में सिस्टम कॉल के समूह को स्पष्ट करने के लिए io_submit चलो एक छोटा प्रोग्राम लिखते हैं जो एक टीसीपी कनेक्शन से दूसरे में डेटा भेजता है। अपने सरलतम रूप में (लिनक्स एआईओ के बिना), यह कुछ इस तरह दिखता है:

 while True: d = sd1.read(4096) sd2.write(d)

हम लिनक्स एआईओ के माध्यम से समान कार्यक्षमता व्यक्त कर सकते हैं। इस मामले में कोड इस तरह होगा:

 struct iocb cb[2] = {{.aio_fildes = sd2,                     .aio_lio_opcode = IOCB_CMD_PWRITE,                     .aio_buf = (uint64_t)&buf[0],                     .aio_nbytes = 0},                    {.aio_fildes = sd1,                    .aio_lio_opcode = IOCB_CMD_PREAD,                    .aio_buf = (uint64_t)&buf[0],                    .aio_nbytes = BUF_SZ}}; struct iocb *list_of_iocb[2] = {&cb[0], &cb[1]}; while(1) { r = io_submit(ctx, 2, list_of_iocb); struct io_event events[2] = {}; r = io_getevents(ctx, 2, 2, events, NULL); cb[0].aio_nbytes = events[1].res; }

यह कोड io_submit दो कार्य जोड़ता है: पहले io_submit लिए एक sd2 अनुरोध, और फिर sd1 से एक पढ़ने का अनुरोध। पढ़ने के बाद, कोड लिखने वाले बफर के आकार को सही करता है और लूप को शुरुआत से दोहराता है। एक चाल है: पहली बार एक लेखन आकार के बफर के साथ होता है 0. यह आवश्यक है क्योंकि हमारे पास लिखने की क्षमता + एक io_submit कॉल में पढ़ने (लेकिन पढ़ने + लिखने नहीं) को संयोजित करने की क्षमता है।

क्या यह कोड रेगुलर read() / write() से ज्यादा तेज है? अभी नहीं। दोनों संस्करण दो सिस्टम कॉल का उपयोग करते हैं: रीड + राइट और io_submit + io_getevents। लेकिन, सौभाग्य से, कोड में सुधार किया जा सकता है।

Io_getevents से छुटकारा पा रहा है

रनटाइम io_setup() कर्नेल प्रक्रिया के लिए मेमोरी के कई पेज आवंटित करता है। इस तरह से यह मेमोरी ब्लॉक / proc // मैप्स में दिखता है:

 marek:~$ cat /proc/`pidof -s aio_passwd`/maps ... 7f7db8f60000-7f7db8f63000 rw-s 00000000 00:12 2314562     /[aio] (deleted) ...

मेमोरी ब्लॉक [aio] (इस मामले में 12 Kb) को io_setup आवंटित किया गया था। इसका उपयोग सर्कुलर बफर के लिए किया जाता है, जहां घटनाओं को संग्रहीत किया जाता है। ज्यादातर मामलों में, io_getevents को कॉल करने का कोई कारण नहीं है - इवेंट पूरा होने वाला डेटा रिंग बफर से कर्नेल मोड पर स्विच करने की आवश्यकता के बिना प्राप्त किया जा सकता है। यहाँ कोड का सही संस्करण है:

 int io_getevents(aio_context_t ctx, long min_nr, long max_nr,                struct io_event *events, struct timespec *timeout) {   int i = 0;   struct aio_ring *ring = (struct aio_ring*)ctx;   if (ring == NULL || ring->magic != AIO_RING_MAGIC) {       goto do_syscall;   }   while (i < max_nr) {       unsigned head = ring->head;       if (head == ring->tail) {           /* There are no more completions */           break;       } else {           /* There is another completion to reap */           events[i] = ring->events[head];           read_barrier();           ring->head = (head + 1) % ring->nr;           i++;       }   }   if (i == 0 && timeout != NULL && timeout->tv_sec == 0 && timeout->tv_nsec == 0) {       /* Requested non blocking operation. */       return 0;   }   if (i && i >= min_nr) {       return i;   } do_syscall:   return syscall(__NR_io_getevents, ctx, min_nr-i, max_nr-i, &events[i], timeout); }

कोड का पूरा संस्करण GitHub पर उपलब्ध है । इस रिंग बफ़र के इंटरफ़ेस को खराब रूप से प्रलेखित किया गया है; लेखक ने कोड को axboe / fio प्रोजेक्ट से अनुकूलित किया है।

इस परिवर्तन के बाद, लिनक्स एआईओ का उपयोग करने वाले कोड के हमारे संस्करण को लूप में केवल एक सिस्टम कॉल की आवश्यकता होती है, जो इसे रीड + राइट का उपयोग करके मूल कोड की तुलना में थोड़ा तेज बनाता है।

फोटो ट्रेन तस्वीरें CC / BY-SA / 2.0

एपोल विकल्प

IOCB_CMD_POLL के कर्नेल संस्करण 4.18 के साथ, io_submit चयन / पोल / एपोल के प्रतिस्थापन के रूप में उपयोग करना संभव हो गया। उदाहरण के लिए, यह कोड नेटवर्क कनेक्शन से डेटा की उम्मीद करेगा:

 struct iocb cb = {.aio_fildes = sd,                 .aio_lio_opcode = IOCB_CMD_POLL,                 .aio_buf = POLLIN}; struct iocb *list_of_iocb[1] = {&cb}; r = io_submit(ctx, 1, list_of_iocb); r = io_getevents(ctx, 1, 1, events, NULL);

पूर्ण कोड । यहाँ उसका स्ट्रेस आउटपुट है:

 io_submit(0x7fe44bddd000, 1, [{aio_lio_opcode=IOCB_CMD_POLL, aio_fildes=3}]) \   = 1 <0.000015> io_getevents(0x7fe44bddd000, 1, 1, [{data=0, obj=0x7ffef65c11a8, res=1, res2=0}], NULL) \   = 1 <1.000377>

जैसा कि आप देख सकते हैं, इस बार अतुल्यकालिक काम किया: io_submit तुरंत निष्पादित, और io_getevents एक सेकंड के लिए अवरुद्ध, डेटा की प्रतीक्षा कर रहा है। इसका उपयोग epoll_wait() सिस्टम कॉल के बजाय किया जा सकता है।

इसके अलावा, epoll साथ काम करने के लिए आमतौर पर epoll_ctl सिस्टम कॉल का उपयोग करने की आवश्यकता होती है। और एप्लिकेशन डेवलपर्स इस फ़ंक्शन पर लगातार कॉल से बचने की कोशिश करते हैं - कारणों को समझने के लिए, बस मैनुअल में EPOLLONESHOT और EPOLLET झंडे पढ़ें । कनेक्शन कनेक्शन के लिए io_submit का उपयोग करके, आप इन कठिनाइयों और अतिरिक्त सिस्टम कॉल से बच सकते हैं। बस iocb वेक्टर से कनेक्शन जोड़ें, io_submit को एक बार कॉल करें और निष्पादन की प्रतीक्षा करें। सब कुछ बहुत सरल है।

सारांश

इस पोस्ट में, हमने लिनक्स एआईओ एपीआई को कवर किया। यह एपीआई मूल रूप से डिस्क के साथ काम करने के लिए डिज़ाइन किया गया था, लेकिन यह नेटवर्क कनेक्शन के साथ भी काम करता है। हालाँकि, नियमित पढ़ने () + लिखने () कॉलों के विपरीत, io_submit का उपयोग करने से आप सिस्टम कॉल को समूहीकृत कर सकते हैं और इस प्रकार प्रदर्शन बढ़ा सकते हैं।

नेटवर्क कनेक्शन के मामले में कर्नेल संस्करण 4.18, io_submit io_getevents साथ शुरू करना, POLLIN और POLLOUT फॉर्म की घटनाओं के लिए उपयोग किया जा सकता है। यह epoll() लिए एक विकल्प है।

मैं एक ऐसी नेटवर्क सेवा की कल्पना कर सकता हूं जो पढ़ने, लिखने, epoll_ctl और epoll_wait के मानक सेट के बजाय केवल io_submit io_getevents का उपयोग करती है। इस मामले में, io_submit में समूह कॉलिंग प्रणाली एक बड़ा लाभ दे सकती है, ऐसा सर्वर बहुत तेज होगा।

दुर्भाग्य से, लिनक्स एआईओ एपीआई में हाल के सुधारों के बाद भी, इसकी उपयोगिता के बारे में चर्चा जारी है। यह सर्वविदित है कि लिनस उससे नफरत करता है :

"AIO घुटने के उच्च डिजाइन का एक भयानक उदाहरण है, जहां मुख्य बहाना है:" अन्य, कम प्रतिभाशाली लोग इसके साथ आए, इसलिए हमें संगतता का अनुपालन करना होगा ताकि डेटाबेस डेवलपर्स (जो शायद ही कभी स्वादिष्ट हों) इसका उपयोग कर सकते हैं। " लेकिन AIO हमेशा बहुत, बहुत कुटिल रही है।

कॉलिंग और एसिंक्रोनसी के लिए एक बेहतर इंटरफ़ेस बनाने के लिए कई प्रयास किए गए हैं, लेकिन उनमें एक सामान्य दृष्टि का अभाव है। उदाहरण के लिए, sendto (MSG_ZEROCOPY) का हालिया जोड़ वास्तव में अतुल्यकालिक डेटा हस्तांतरण की अनुमति देता है, लेकिन समूहीकरण के लिए प्रदान नहीं करता है। io_submit समूहीकरण के लिए प्रदान करता है, लेकिन अतुल्यकालिक नहीं। इससे भी बदतर - वर्तमान में लिनक्स पर अतुल्यकालिक घटनाओं को वितरित करने के तीन तरीके हैं: सिग्नल, io_getevents और MSG_ERRQUEUE।

किसी भी मामले में, यह बहुत अच्छा है कि नेटवर्क सेवाओं के काम को गति देने के लिए नए तरीके हैं।

io_submit: आपके द्वारा कभी नहीं सुना गया एपोल का एक विकल्प