Elasticsearch cluster 200 TB+

មនុស្សជាច្រើនតស៊ូជាមួយ Elasticsearch ។ ប៉ុន្តែតើមានអ្វីកើតឡើងនៅពេលដែលអ្នកចង់ប្រើវាដើម្បីរក្សាទុកកំណត់ហេតុ "ក្នុងបរិមាណដ៏ច្រើន"? ហើយតើវាគ្មានការឈឺចាប់ទេក្នុងការជួបប្រទះនឹងការបរាជ័យនៃមជ្ឈមណ្ឌលទិន្នន័យណាមួយ? តើ​ស្ថាបត្យកម្ម​ប្រភេទ​ណា​ដែល​អ្នក​គួរ​បង្កើត ហើយ​តើ​អ្នក​នឹង​ជួប​បញ្ហា​អ្វីខ្លះ​?

យើងនៅ Odnoklassniki បានសម្រេចចិត្តប្រើ elasticsearch ដើម្បីដោះស្រាយបញ្ហានៃការគ្រប់គ្រងកំណត់ហេតុ ហើយឥឡូវនេះយើងចែករំលែកបទពិសោធន៍របស់យើងជាមួយ Habr៖ ទាំងអំពីស្ថាបត្យកម្ម និងអំពីរណ្តៅ។

ខ្ញុំគឺ Pyotr Zaitsev ខ្ញុំធ្វើការជាអ្នកគ្រប់គ្រងប្រព័ន្ធនៅ Odnoklassniki ។ មុននោះ ខ្ញុំក៏ជាអ្នកគ្រប់គ្រងម្នាក់ដែរ ធ្វើការជាមួយ Manticore Search, Sphinx search, Elasticsearch ។ ប្រហែល​ជា​ប្រសិន​បើ​ការ​ស្វែង​រក​មួយ​ផ្សេង​ទៀត​លេច​ឡើង ខ្ញុំ​ប្រហែល​ជា​នឹង​ធ្វើ​ការ​ជាមួយ​វា​ផង​ដែរ។ ខ្ញុំក៏ចូលរួមនៅក្នុងគម្រោងប្រភពបើកចំហមួយចំនួននៅលើមូលដ្ឋានស្ម័គ្រចិត្ត។

នៅពេលខ្ញុំមកដល់ Odnoklassniki ខ្ញុំបាននិយាយដោយមិនប្រុងប្រយ័ត្ននៅឯបទសម្ភាសន៍ថាខ្ញុំអាចធ្វើការជាមួយ Elasticsearch ។ បន្ទាប់​ពី​ខ្ញុំ​ទទួល​បាន​ការ​ព្យួរ​វា​ហើយ​បាន​បញ្ចប់​កិច្ចការ​សាមញ្ញ​មួយ​ចំនួន ខ្ញុំ​ត្រូវ​បាន​ផ្តល់​ឱ្យ​នូវ​កិច្ចការ​ដ៏​ធំ​ក្នុង​ការ​កែទម្រង់​ប្រព័ន្ធ​គ្រប់គ្រង​កំណត់ហេតុ​ដែល​មាន​នៅ​ពេល​នោះ។

តម្រូវការ

តម្រូវការប្រព័ន្ធត្រូវបានរៀបចំដូចខាងក្រោមៈ

• Graylog នឹងត្រូវប្រើជាផ្នែកខាងមុខ។ ដោយសារតែក្រុមហ៊ុនមានបទពិសោធន៍ប្រើប្រាស់ផលិតផលនេះរួចហើយ អ្នកសរសេរកម្មវិធី និងអ្នកសាកល្បងបានដឹង វាស៊ាំ និងងាយស្រួលសម្រាប់ពួកគេ។
• បរិមាណទិន្នន័យ៖ ជាមធ្យម 50-80 ពាន់សារក្នុងមួយវិនាទី ប៉ុន្តែប្រសិនបើមានអ្វីមួយដាច់ នោះចរាចរណ៍មិនត្រូវបានកំណត់ដោយអ្វីនោះទេ វាអាចមាន 2-3 លានបន្ទាត់ក្នុងមួយវិនាទី
• ដោយបានពិភាក្សាជាមួយអតិថិជនអំពីតម្រូវការសម្រាប់ល្បឿននៃដំណើរការសំណួរស្វែងរក យើងបានដឹងថាគំរូធម្មតានៃការប្រើប្រាស់ប្រព័ន្ធបែបនេះគឺ៖ មនុស្សកំពុងស្វែងរកកំណត់ហេតុនៃកម្មវិធីរបស់ពួកគេសម្រាប់រយៈពេលពីរថ្ងៃចុងក្រោយ ហើយមិនចង់រង់ចាំច្រើនជាងមួយ ទីពីរសម្រាប់លទ្ធផលនៃសំណួរដែលបានបង្កើត។
• អ្នកគ្រប់គ្រងបានទទូចថាប្រព័ន្ធនេះអាចធ្វើមាត្រដ្ឋានបានយ៉ាងងាយស្រួលប្រសិនបើចាំបាច់ដោយមិនតម្រូវឱ្យពួកគេស្វែងយល់ឱ្យស៊ីជម្រៅអំពីរបៀបដែលវាដំណើរការ។
• ដូច្នេះ ភារកិច្ចថែទាំតែមួយគត់ដែលប្រព័ន្ធទាំងនេះត្រូវការជាទៀងទាត់គឺការផ្លាស់ប្តូរផ្នែករឹងមួយចំនួន។
• លើសពីនេះទៀត Odnoklassniki មានប្រពៃណីបច្ចេកទេសដ៏ល្អមួយ៖ សេវាកម្មណាមួយដែលយើងបើកដំណើរការត្រូវតែរួចផុតពីការបរាជ័យនៃមជ្ឈមណ្ឌលទិន្នន័យ (ភ្លាមៗ មិនបានគ្រោងទុក និងពិតប្រាកដនៅពេលណាក៏បាន)។

តម្រូវការចុងក្រោយក្នុងការអនុវត្តគម្រោងនេះធ្វើឱ្យយើងខាតបង់ច្រើនបំផុត ដែលខ្ញុំនឹងនិយាយលម្អិតបន្ថែមទៀត។

ថ្ងៃពុធ

យើងធ្វើការនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យចំនួនបួន ខណៈពេលដែលថ្នាំងទិន្នន័យ Elasticsearch អាចមានទីតាំងនៅបីប៉ុណ្ណោះ (សម្រាប់ហេតុផលមួយចំនួនដែលមិនមែនជាបច្ចេកទេស)។

មជ្ឈមណ្ឌលទិន្នន័យទាំងបួននេះមានប្រហែល 18 ពាន់ប្រភពកំណត់ហេតុផ្សេងៗគ្នា - ផ្នែករឹង ឧបករណ៍ផ្ទុក ម៉ាស៊ីននិម្មិត។

លក្ខណៈសំខាន់៖ ចង្កោមចាប់ផ្តើមនៅក្នុងធុង ផូមេន មិនមែននៅលើម៉ាស៊ីនរូបវ័ន្តទេ ប៉ុន្តែនៅលើ ផលិតផលពពកផ្ទាល់ខ្លួនមួយពពក. កុងតឺន័រត្រូវបានធានា 2 ស្នូល ស្រដៀងទៅនឹង 2.0Ghz v4 ជាមួយនឹងលទ្ធភាពនៃការកែច្នៃស្នូលដែលនៅសល់ ប្រសិនបើពួកវាទំនេរ។

ក្នុង​ន័យ​ផ្សេងទៀត:

តូប៉ូឡូញ

ដំបូងខ្ញុំឃើញទម្រង់ទូទៅនៃដំណោះស្រាយដូចខាងក្រោម៖

• VIPs 3-4 នៅពីក្រោយ A-record នៃដែន Graylog នេះគឺជាអាសយដ្ឋានដែលកំណត់ហេតុត្រូវបានផ្ញើ។
• VIP នីមួយៗគឺជាអ្នករក្សាតុល្យភាព LVS ។
• បន្ទាប់ពីវា កំណត់ហេតុចូលទៅកាន់ថ្ម Graylog ទិន្នន័យខ្លះស្ថិតក្នុងទម្រង់ GELF ខ្លះជាទម្រង់ syslog។
• បន្ទាប់មកអ្វីៗទាំងអស់នេះត្រូវបានសរសេរជាបាច់ធំទៅកាន់ថ្មរបស់អ្នកសម្របសម្រួល Elasticsearch ។
• ហើយពួកគេបញ្ជូនសំណើសរសេរ និងអានទៅកាន់ថ្នាំងទិន្នន័យដែលពាក់ព័ន្ធ។

ស័ព្ទ

ប្រហែលជាមិនមែនគ្រប់គ្នាយល់ពីវាក្យសព្ទឱ្យបានលម្អិតទេ ដូច្នេះខ្ញុំចង់រស់នៅលើវាបន្តិច។

Elasticsearch មានថ្នាំងជាច្រើនប្រភេទ - មេ អ្នកសម្របសម្រួល ថ្នាំងទិន្នន័យ។ មានប្រភេទពីរផ្សេងទៀតសម្រាប់ការបំប្លែងកំណត់ហេតុផ្សេងគ្នា និងការទំនាក់ទំនងរវាងចង្កោមផ្សេងៗគ្នា ប៉ុន្តែយើងបានប្រើតែប្រភេទដែលបានរាយបញ្ជីប៉ុណ្ណោះ។

អនុបណ្ឌិត
វាដាក់ថ្នាំងទាំងអស់ដែលមានវត្តមាននៅក្នុងចង្កោម រក្សាផែនទីចង្កោមដែលទាន់សម័យ និងចែកចាយវារវាងថ្នាំង ដំណើរការតក្កវិជ្ជាព្រឹត្តិការណ៍ និងអនុវត្តប្រភេទផ្សេងៗនៃការថែរក្សាផ្ទះធំទូលាយនៃចង្កោម។

អ្នកសំរបសំរួល
អនុវត្តកិច្ចការតែមួយ៖ ទទួលយកការអាន ឬសរសេរសំណើពីអតិថិជន និងបញ្ជូនចរាចរណ៍នេះ។ ក្នុងករណីមានសំណើសរសេរ ភាគច្រើនទំនងជាវានឹងសួរមេថាតើផ្នែកណាមួយនៃលិបិក្រមដែលពាក់ព័ន្ធដែលវាគួរតែដាក់វា ហើយនឹងប្តូរទិសសំណើបន្ថែមទៀត។

ថ្នាំងទិន្នន័យ
រក្សាទុកទិន្នន័យ អនុវត្តសំណួរស្វែងរកដែលមកដល់ពីខាងក្រៅ និងអនុវត្តប្រតិបត្តិការនៅលើ shards ដែលមានទីតាំងនៅលើវា។

ប្រផេះ
នេះ​គឺ​ជា​អ្វី​មួយ​ដូច​ជា​ការ​លាយ​បញ្ចូល​គ្នា​នៃ Kibana ជាមួយ Logstash ក្នុង​ជង់ ELK។ Graylog រួមបញ្ចូលគ្នាទាំង UI និងបំពង់ដំណើរការកំណត់ហេតុ។ នៅក្រោមក្រណាត់ Graylog ដំណើរការ Kafka និង Zookeeper ដែលផ្តល់ការតភ្ជាប់ទៅ Graylog ជាចង្កោម។ Graylog អាច​ទុក​កំណត់​ហេតុ (Kafka) ក្នុង​ករណី​ដែល Elasticsearch មិន​អាច​ប្រើ​បាន ហើយ​ធ្វើ​សំណើ​អាន​និង​សរសេរ​ដែល​មិន​ជោគជ័យ ធ្វើ​ជា​ក្រុម និង​សម្គាល់​កំណត់​ហេតុ​តាម​ច្បាប់​ដែល​បាន​បញ្ជាក់។ ដូច Logstash ដែរ Graylog មានមុខងារដើម្បីកែប្រែជួរមុនពេលសរសេរពួកវាទៅ Elasticsearch ។

លើសពីនេះ Graylog មានការរកឃើញសេវាកម្មដែលភ្ជាប់មកជាមួយ ដែលអនុញ្ញាតឱ្យផ្អែកលើថ្នាំង Elasticsearch ដែលអាចប្រើបាន ដើម្បីទទួលបានផែនទីចង្កោមទាំងមូល និងត្រងវាដោយស្លាកជាក់លាក់ ដែលធ្វើឱ្យវាអាចធ្វើទៅបានដើម្បីដឹកនាំសំណើទៅកាន់កុងតឺន័រជាក់លាក់។

តាមទស្សនៈវាមើលទៅដូចនេះ៖

នេះគឺជារូបថតអេក្រង់ពីឧទាហរណ៍ជាក់លាក់មួយ។ នៅទីនេះយើងបង្កើតអ៊ីស្តូក្រាមដោយផ្អែកលើសំណួរស្វែងរក និងបង្ហាញជួរដែលពាក់ព័ន្ធ។

សន្ទស្សន៍

ត្រលប់ទៅស្ថាបត្យកម្មប្រព័ន្ធវិញ ខ្ញុំចង់និយាយលម្អិតបន្ថែមទៀតអំពីរបៀបដែលយើងបង្កើតគំរូលិបិក្រម ដើម្បីឱ្យវាដំណើរការបានត្រឹមត្រូវ។

នៅក្នុងដ្យាក្រាមខាងលើ នេះគឺជាកម្រិតទាបបំផុត៖ ថ្នាំងទិន្នន័យ Elasticsearch ។

សន្ទស្សន៍គឺជាអង្គភាពនិម្មិតដ៏ធំមួយដែលបង្កើតឡើងដោយ Elasticsearch shards ។ នៅក្នុងខ្លួនវា, shards នីមួយៗគឺគ្មានអ្វីក្រៅពីសន្ទស្សន៍ Lucene ទេ។ ហើយសន្ទស្សន៍ Lucene នីមួយៗមានផ្នែកមួយ ឬច្រើន។

នៅពេលរចនា យើងបានគិតថា ដើម្បីបំពេញតម្រូវការសម្រាប់ល្បឿនអានទិន្នន័យក្នុងបរិមាណដ៏ច្រើន យើងត្រូវ "រីករាលដាល" ទិន្នន័យនេះឱ្យស្មើៗគ្នានៅលើថ្នាំងទិន្នន័យ។

នេះបណ្តាលឱ្យការពិតដែលថាចំនួន shards ក្នុងមួយលិបិក្រម (ជាមួយការចម្លង) គួរតែស្មើយ៉ាងតឹងរឹងទៅនឹងចំនួនថ្នាំងទិន្នន័យ។ ទីមួយ ដើម្បីធានាបាននូវកត្តាចម្លងស្មើនឹងពីរ (នោះគឺយើងអាចបាត់បង់ពាក់កណ្តាលនៃចង្កោម)។ ហើយទីពីរ ដើម្បីដំណើរការការអាន និងសរសេរសំណើនៅលើយ៉ាងហោចណាស់ពាក់កណ្តាលនៃចង្កោម។

ដំបូង​យើង​កំណត់​រយៈពេល​ផ្ទុក​ជា 30 ថ្ងៃ។

ការចែកចាយនៃ shards អាចត្រូវបានតំណាងជាក្រាហ្វិកដូចខាងក្រោម:

ចតុកោណកែងពណ៌ប្រផេះងងឹតទាំងមូលគឺជាលិបិក្រម។ ការ៉េ​ក្រហម​ខាង​ឆ្វេង​នៅ​ក្នុង​វា​គឺ​ជា shard បឋម ដែល​ជា​ទីមួយ​ក្នុង​លិបិក្រម។ ហើយការ៉េពណ៌ខៀវគឺជាបន្ទះចម្លង ពួកគេមានទីតាំងនៅមជ្ឈមណ្ឌលទិន្នន័យផ្សេងៗគ្នា។

នៅពេលដែលយើងបន្ថែម shard មួយផ្សេងទៀត វាទៅមជ្ឈមណ្ឌលទិន្នន័យទីបី។ ហើយនៅទីបញ្ចប់ យើងទទួលបានរចនាសម្ព័ន្ធនេះ ដែលធ្វើឱ្យវាអាចបាត់បង់ DC ដោយមិនបាត់បង់ភាពស៊ីសង្វាក់គ្នានៃទិន្នន័យ៖

ការបង្វិលសន្ទស្សន៍, i.e. បង្កើតលិបិក្រមថ្មី ហើយលុបលេខចាស់បំផុត យើងបានធ្វើឱ្យវាស្មើនឹង 48 ម៉ោង (យោងទៅតាមគំរូនៃការប្រើប្រាស់លិបិក្រម៖ 48 ម៉ោងចុងក្រោយត្រូវបានស្វែងរកញឹកញាប់បំផុត)។

ចន្លោះពេលបង្វិលសន្ទស្សន៍នេះគឺដោយសារហេតុផលដូចខាងក្រោម៖

នៅពេលដែលសំណើស្វែងរកមកដល់ថ្នាំងទិន្នន័យជាក់លាក់មួយ បន្ទាប់មកតាមទស្សនៈនៃការអនុវត្ត វាមានផលចំណេញច្រើនជាងនៅពេលដែល shard មួយត្រូវបានសួរ ប្រសិនបើទំហំរបស់វាអាចប្រៀបធៀបទៅនឹងទំហំនៃត្រគាករបស់ថ្នាំង។ នេះអនុញ្ញាតឱ្យអ្នករក្សាផ្នែក "ក្តៅ" នៃលិបិក្រមនៅក្នុងបណ្តុំ ហើយចូលប្រើវាយ៉ាងរហ័ស។ នៅពេលដែលមាន "ផ្នែកក្តៅ" ជាច្រើន ល្បឿននៃការស្វែងរកលិបិក្រមធ្លាក់ចុះ។

នៅពេលដែលថ្នាំងចាប់ផ្តើមដំណើរការសំណួរស្វែងរកនៅលើ shard មួយ វាបែងចែកចំនួននៃ threads ស្មើនឹងចំនួននៃ hyperthreading cores នៃម៉ាស៊ីនរូបវន្ត។ ប្រសិនបើសំណួរស្វែងរកប៉ះពាល់ដល់ចំនួនដ៏ច្រើននៃ shards នោះចំនួននៃខ្សែស្រឡាយកើនឡើងតាមសមាមាត្រ។ នេះជះឥទ្ធិពលអវិជ្ជមានលើល្បឿនស្វែងរក និងជះឥទ្ធិពលអវិជ្ជមានដល់ការធ្វើលិបិក្រមនៃទិន្នន័យថ្មី។

ដើម្បីផ្តល់ភាពយឺតយ៉ាវក្នុងការស្វែងរក យើងបានសម្រេចចិត្តប្រើ SSD។ ដើម្បីដំណើរការសំណើបានឆាប់រហ័ស ម៉ាស៊ីនដែលផ្ទុកធុងទាំងនេះត្រូវតែមានយ៉ាងហោចណាស់ 56 ស្នូល។ តួលេខ 56 ត្រូវបានជ្រើសរើសជាតម្លៃគ្រប់គ្រាន់តាមលក្ខខណ្ឌដែលកំណត់ចំនួនខ្សែស្រឡាយដែល Elasticsearch នឹងបង្កើតកំឡុងប្រតិបត្តិការ។ នៅក្នុង Elasitcsearch ប៉ារ៉ាម៉ែត្រនៃបណ្តុំខ្សែស្រឡាយជាច្រើនអាស្រ័យដោយផ្ទាល់ទៅលើចំនួនស្នូលដែលមាន ដែលជះឥទ្ធិពលដោយផ្ទាល់ទៅលើចំនួនថ្នាំងដែលត្រូវការនៅក្នុងចង្កោមយោងទៅតាមគោលការណ៍ "ស្នូលតិចជាង - ថ្នាំងកាន់តែច្រើន" ។

ជាលទ្ធផល យើងបានរកឃើញថាជាមធ្យម shard មួយមានទម្ងន់ប្រហែល 20 ជីហ្គាបៃ ហើយមាន 1 shards ក្នុងមួយលិបិក្រម។ ដូច្នោះហើយ ប្រសិនបើយើងបង្វិលពួកវាម្តងរៀងរាល់ 360 ម៉ោង នោះយើងមាន 48 ក្នុងចំណោមពួកគេ។ សន្ទស្សន៍នីមួយៗមានទិន្នន័យរយៈពេល 15 ថ្ងៃ។

សៀគ្វីអាននិងសរសេរទិន្នន័យ

ចូរយើងស្វែងយល់ពីរបៀបដែលទិន្នន័យត្រូវបានកត់ត្រានៅក្នុងប្រព័ន្ធនេះ។

ចូរនិយាយថាសំណើមួយចំនួនបានមកដល់ពី Graylog ទៅកាន់អ្នកសម្របសម្រួល។ ឧទាហរណ៍យើងចង់ដាក់សន្ទស្សន៍ 2-3 ពាន់ជួរ។

អ្នកសម្របសម្រួលដោយបានទទួលសំណើពី Graylog សួរមេថា "នៅក្នុងសំណើសុំធ្វើលិបិក្រម យើងបានបញ្ជាក់យ៉ាងជាក់លាក់នូវលិបិក្រម ប៉ុន្តែក្នុងអ្វីដែលពិបាកសរសេរវាមិនត្រូវបានបញ្ជាក់ទេ។"

មេឆ្លើយតប៖ "សរសេរព័ត៌មាននេះទៅលេខ shard 71" បន្ទាប់ពីនោះវាត្រូវបានផ្ញើដោយផ្ទាល់ទៅថ្នាំងទិន្នន័យដែលពាក់ព័ន្ធ ដែលលេខបឋម-shard លេខ 71 ស្ថិតនៅ។

បន្ទាប់ពីនោះកំណត់ហេតុប្រតិបត្តិការត្រូវបានចម្លងទៅ replica-shard ដែលមានទីតាំងនៅមជ្ឈមណ្ឌលទិន្នន័យផ្សេងទៀត។

សំណើស្វែងរកមកដល់ពី Graylog ទៅកាន់អ្នកសម្របសម្រួល។ អ្នកសម្របសម្រួលបង្វែរវាទៅតាមសន្ទស្សន៍ ខណៈពេលដែល Elasticsearch ចែកចាយសំណើរវាង primary-shard និង replica-shard ដោយប្រើគោលការណ៍ round-robin ។

ថ្នាំង 180 ឆ្លើយតបមិនស្មើគ្នា ហើយខណៈពេលដែលពួកគេកំពុងឆ្លើយតប អ្នកសម្របសម្រួលកំពុងប្រមូលព័ត៌មានដែលត្រូវបាន "ស្ដោះចេញ" រួចហើយដោយថ្នាំងទិន្នន័យលឿនជាងមុន។ បន្ទាប់ពីនេះ នៅពេលដែលព័ត៌មានទាំងអស់បានមកដល់ ឬសំណើបានដល់ពេលកំណត់ វាផ្តល់អ្វីៗគ្រប់យ៉ាងដោយផ្ទាល់ដល់អតិថិជន។

ប្រព័ន្ធទាំងមូលនេះជាមធ្យមដំណើរការសំណួរស្វែងរកក្នុងរយៈពេល 48 ម៉ោងចុងក្រោយក្នុងរយៈពេល 300-400ms ដោយមិនរាប់បញ្ចូលសំណួរទាំងនោះដែលមានអក្សរជំនួសនាំមុខ។

ផ្កាជាមួយ Elasticsearch៖ ការរៀបចំ Java

ដើម្បីធ្វើឱ្យវាដំណើរការទាំងអស់ដូចដែលយើងចង់បាន យើងបានចំណាយពេលយូរណាស់ក្នុងការបំបាត់កំហុសជាច្រើននៅក្នុងចង្កោម។

ផ្នែកដំបូងនៃបញ្ហាដែលបានរកឃើញគឺទាក់ទងទៅនឹងវិធីដែល Java ត្រូវបានកំណត់ជាមុនតាមលំនាំដើមនៅក្នុង Elasticsearch ។

បញ្ហាមួយ។
យើងបានឃើញរបាយការណ៍មួយចំនួនធំដែលថានៅកម្រិត Lucene នៅពេលដែលការងារផ្ទៃខាងក្រោយកំពុងដំណើរការ ផ្នែក Lucene បញ្ចូលគ្នាបានបរាជ័យដោយមានកំហុស។ ក្នុងពេលជាមួយគ្នានេះ វាច្បាស់ណាស់នៅក្នុងកំណត់ហេតុថានេះគឺជាកំហុស OutOfMemoryError ។ យើងបានឃើញតាមតេឡេម៉ែត្រថាត្រគាកទំនេរ ហើយវាមិនច្បាស់ថាហេតុអ្វីបានជាប្រតិបត្តិការនេះបរាជ័យ។

វាបានប្រែក្លាយថាការបញ្ចូលគ្នានៃសន្ទស្សន៍ Lucene កើតឡើងនៅខាងក្រៅត្រគាក។ ហើយកុងតឺន័រត្រូវបានកំណត់យ៉ាងតឹងរ៉ឹងចំពោះធនធានដែលប្រើប្រាស់។ មានតែ heap ប៉ុណ្ណោះដែលអាចសមនឹងធនធានទាំងនេះ (តម្លៃ heap.size គឺប្រហែលស្មើនឹង RAM) ហើយប្រតិបត្តិការក្រៅ heap មួយចំនួនបានគាំងជាមួយនឹងកំហុសក្នុងការបែងចែកអង្គចងចាំ ប្រសិនបើសម្រាប់ហេតុផលមួយចំនួន ពួកវាមិនសមនឹង ~ 500MB ដែលនៅមុនពេលកំណត់។

ការជួសជុលនេះគឺតូចតាចណាស់៖ ចំនួន RAM ដែលមានសម្រាប់កុងតឺន័រត្រូវបានកើនឡើង បន្ទាប់ពីនោះយើងភ្លេចថាយើងមានបញ្ហាបែបនេះ។

បញ្ហា​ទី​ពីរ
4-5 ថ្ងៃបន្ទាប់ពីការបើកដំណើរការនៃចង្កោម យើងសង្កេតឃើញថាថ្នាំងទិន្នន័យចាប់ផ្តើមចេញពីចង្កោមជាទៀងទាត់ ហើយបញ្ចូលវាបន្ទាប់ពី 10-20 វិនាទី។

នៅពេលដែលយើងចាប់ផ្តើមស្វែងយល់ វាបានប្រែក្លាយថាអង្គចងចាំដែលបិទនៅក្នុង Elasticsearch មិនត្រូវបានគ្រប់គ្រងតាមមធ្យោបាយណាមួយឡើយ។ នៅពេលដែលយើងផ្តល់អង្គចងចាំបន្ថែមដល់កុងតឺន័រ យើងអាចបំពេញបណ្តុំបណ្តោះអាសន្នដោយផ្ទាល់ជាមួយនឹងព័ត៌មានផ្សេងៗ ហើយវាត្រូវបានជម្រះតែបន្ទាប់ពី GC ច្បាស់លាស់ត្រូវបានចាប់ផ្តើមពី Elasticsearch ។

ក្នុងករណីខ្លះ ប្រតិបត្តិការនេះចំណាយពេលយូរណាស់ ហើយក្នុងអំឡុងពេលនេះ ចង្កោមបានគ្រប់គ្រងដើម្បីសម្គាល់ថ្នាំងនេះថាបានចេញរួចហើយ។ បញ្ហានេះត្រូវបានពិពណ៌នាយ៉ាងល្អ នៅទីនេះ.

ដំណោះស្រាយមានដូចខាងក្រោម៖ យើងបានកំណត់សមត្ថភាពរបស់ Java ក្នុងការប្រើអង្គចងចាំភាគច្រើននៅខាងក្រៅឃ្លាំងសម្រាប់ប្រតិបត្តិការទាំងនេះ។ យើងបានកំណត់វាត្រឹម 16 ជីហ្គាបៃ (-XX:MaxDirectMemorySize=16g) ដោយធានាថា GC ច្បាស់លាស់ត្រូវបានហៅញឹកញាប់ជាង និងដំណើរការលឿនជាងមុន ដូច្នេះវាលែងធ្វើឱ្យចង្កោមមានអស្ថិរភាពទៀតហើយ។

បញ្ហាបី
ប្រសិនបើអ្នកគិតថាបញ្ហាជាមួយ "ថ្នាំងចាកចេញពីចង្កោមនៅពេលដែលមិននឹកស្មានដល់បំផុត" ត្រូវបានបញ្ចប់ នោះអ្នកយល់ខុសហើយ។

នៅពេលយើងកំណត់រចនាសម្ព័ន្ធការងារជាមួយលិបិក្រម យើងបានជ្រើសរើស mmapfs ទៅ កាត់បន្ថយពេលវេលាស្វែងរក នៅលើ shards ស្រស់ជាមួយនឹងការបែងចែកដ៏អស្ចារ្យ។ នេះ​ជា​ការ​មិន​ពិត​ទេ ព្រោះ​ពេល​ប្រើ mmapfs ឯកសារ​ត្រូវ​បាន​ផ្គូផ្គង​ទៅ​ក្នុង RAM ហើយ​បន្ទាប់​មក​យើង​ធ្វើ​ការ​ជាមួយ​ឯកសារ​ដែល​បាន​ផែនទី។ ដោយសារតែនេះ វាប្រែថានៅពេលដែល GC ព្យាយាមបញ្ឈប់ខ្សែស្រឡាយនៅក្នុងកម្មវិធី យើងទៅកន្លែងសុវត្ថិភាពអស់រយៈពេលជាយូរ ហើយនៅតាមផ្លូវទៅវា កម្មវិធីឈប់ឆ្លើយតបនឹងសំណើរបស់មេអំពីថាតើវានៅរស់ឬអត់។ . ដូច្នោះហើយ មេជឿថាថ្នាំងលែងមាននៅក្នុងចង្កោមទៀតហើយ។ បន្ទាប់ពីនេះបន្ទាប់ពី 5-10 វិនាទីអ្នកប្រមូលសំរាមដំណើរការថ្នាំងមានជីវិតចូលក្នុងចង្កោមម្តងទៀតហើយចាប់ផ្តើមបង្កើតបំណែក។ វាទាំងអស់មានអារម្មណ៍ដូចជា "ផលិតកម្មដែលយើងសមនឹងទទួលបាន" ហើយមិនសមរម្យសម្រាប់អ្វីដែលធ្ងន់ធ្ងរនោះទេ។

ដើម្បីកម្ចាត់ឥរិយាបទនេះ ដំបូងយើងប្តូរទៅ niofs ស្តង់ដារ ហើយបន្ទាប់មក នៅពេលដែលយើងផ្លាស់ប្តូរពី Elastic ជំនាន់ទី 5 ដល់ទី 6 យើងបានសាកល្បង hybridfs ដែលបញ្ហានេះមិនត្រូវបានបង្កើតឡើងវិញទេ។ អ្នកអាចអានបន្ថែមអំពីប្រភេទការផ្ទុក នៅទីនេះ.

បញ្ហាទីបួន
បន្ទាប់មកមានបញ្ហាគួរឱ្យចាប់អារម្មណ៍មួយទៀតដែលយើងបានព្យាបាលក្នុងរយៈពេលកំណត់មួយ។ យើងចាប់វាបានរយៈពេល 2-3 ខែ ពីព្រោះលំនាំរបស់វាមិនអាចយល់បាន។

ពេលខ្លះអ្នកសម្របសម្រួលរបស់យើងបានទៅ Full GC ជាធម្មតាពេលខ្លះបន្ទាប់ពីអាហារថ្ងៃត្រង់ ហើយមិនដែលត្រលប់ពីទីនោះទេ។ នៅពេលដំណាលគ្នានៅពេលចូលការពន្យារពេល GC វាមើលទៅដូចនេះ: អ្វីៗដំណើរការល្អ ល្អ ល្អ ហើយភ្លាមៗនោះអ្វីៗនឹងអាក្រក់ណាស់។

ដំបូង​ឡើយ យើង​គិត​ថា​យើង​មាន​អ្នក​ប្រើ​អាក្រក់​ដែល​កំពុង​បើក​សំណើ​ប្រភេទ​មួយ​ចំនួន​ដែល​ធ្វើ​ឲ្យ​អ្នក​សម្រប​សម្រួល​ចេញ​ពី​របៀប​ធ្វើការ។ យើងបានកត់ត្រាសំណើអស់រយៈពេលជាយូរណាស់មកហើយ ដោយព្យាយាមស្វែងយល់ថាមានអ្វីកើតឡើង។

ជាលទ្ធផល វាបានប្រែក្លាយថា នៅពេលអ្នកប្រើប្រាស់ចាប់ផ្តើមសំណើដ៏ធំមួយ ហើយវាទៅដល់អ្នកសម្របសម្រួល Elasticsearch ជាក់លាក់ ថ្នាំងមួយចំនួនឆ្លើយតបយូរជាងអ្នកដទៃ។

ហើយខណៈពេលដែលអ្នកសម្របសម្រួលកំពុងរង់ចាំការឆ្លើយតបពីថ្នាំងទាំងអស់ គាត់ប្រមូលលទ្ធផលដែលបានផ្ញើពីថ្នាំងដែលបានឆ្លើយតបរួចហើយ។ សម្រាប់ GC នេះមានន័យថាទម្រង់នៃការប្រើប្រាស់ heap របស់យើងផ្លាស់ប្តូរយ៉ាងឆាប់រហ័ស។ ហើយ GC ដែលយើងធ្លាប់ប្រើមិនអាចទប់ទល់នឹងកិច្ចការនេះបានទេ។

ការជួសជុលតែមួយគត់ដែលយើងបានរកឃើញដើម្បីផ្លាស់ប្តូរឥរិយាបថរបស់ចង្កោមក្នុងស្ថានភាពនេះគឺការធ្វើចំណាកស្រុកទៅ JDK13 និងការប្រើប្រាស់អ្នកប្រមូលសំរាម Shenandoah ។ នេះបានដោះស្រាយបញ្ហាអ្នកសម្របសម្រួលរបស់យើងឈប់ធ្លាក់ចុះ។

នេះគឺជាកន្លែងដែលបញ្ហាជាមួយ Java បានបញ្ចប់ ហើយបញ្ហាកម្រិតបញ្ជូនបានចាប់ផ្តើម។

"ផ្លែប៊ឺរី" ជាមួយ Elasticsearch: ឆ្លងកាត់

បញ្ហាជាមួយការបញ្ជូនទិន្នន័យមានន័យថា ចង្កោមរបស់យើងដំណើរការប្រកបដោយស្ថិរភាព ប៉ុន្តែនៅកម្រិតខ្ពស់បំផុតនៃចំនួនឯកសារដែលបានធ្វើលិបិក្រម និងអំឡុងពេលធ្វើសមយុទ្ធ ប្រតិបត្តិការគឺមិនគ្រប់គ្រាន់ទេ។

រោគសញ្ញាដំបូងដែលបានជួបប្រទះ៖ ក្នុងអំឡុងពេល "ការផ្ទុះ" មួយចំនួននៅក្នុងផលិតកម្ម នៅពេលដែលកំណត់ហេតុមួយចំនួនធំត្រូវបានបង្កើតភ្លាមៗ កំហុសក្នុងការធ្វើលិបិក្រម es_rejected_execution ចាប់ផ្តើមបង្ហាញជាញឹកញាប់នៅក្នុង Graylog ។

នេះគឺដោយសារតែការពិតដែលថា thread_pool.write.queue នៅលើថ្នាំងទិន្នន័យមួយ រហូតដល់ពេលដែល Elasticsearch អាចដំណើរការសំណើរបង្កើតលិបិក្រម និងបង្ហោះព័ត៌មានទៅ shard នៅលើថាស គឺអាចផ្ទុកសំណើបានតែ 200 ប៉ុណ្ណោះតាមលំនាំដើម។ ហើយនៅក្នុង ឯកសារ Elasticsearch មានការនិយាយតិចតួចអំពីប៉ារ៉ាម៉ែត្រនេះ។ មានតែចំនួនអតិបរមានៃខ្សែស្រឡាយ និងទំហំលំនាំដើមប៉ុណ្ណោះដែលត្រូវបានចង្អុលបង្ហាញ។

ជាការពិតណាស់ យើងបានទៅកែប្រែតម្លៃនេះ ហើយបានរកឃើញដូចខាងក្រោម៖ ជាពិសេស នៅក្នុងការរៀបចំរបស់យើង សំណើរហូតដល់ 300 ត្រូវបានទុកក្នុងឃ្លាំងសម្ងាត់យ៉ាងល្អ ហើយតម្លៃកាន់តែខ្ពស់គឺមានភាពស្រពិចស្រពិលជាមួយនឹងការពិតដែលថាយើងហោះហើរទៅកាន់ Full GC ម្តងទៀត។

លើសពីនេះ ដោយសារទាំងនេះជាបណ្តុំនៃសារដែលមកដល់ក្នុងសំណើមួយ វាចាំបាច់ក្នុងការកែប្រែ Graylog ដើម្បីឱ្យវាសរសេរមិនញឹកញាប់ និងជាបាច់តូចៗ ប៉ុន្តែជាបាច់ធំ ឬម្តងរៀងរាល់ 3 វិនាទី ប្រសិនបើបាច់នៅតែមិនពេញលេញ។ ក្នុងករណីនេះ វាប្រែថាព័ត៌មានដែលយើងសរសេរក្នុង Elasticsearch អាចរកបានមិនមែនក្នុងរយៈពេលពីរវិនាទីនោះទេ ប៉ុន្តែជាប្រាំ (ដែលសាកសមនឹងយើងខ្លាំង) ប៉ុន្តែចំនួននៃការដកថយដែលត្រូវធ្វើដើម្បីរុញច្រានឱ្យកាន់តែធំ។ បណ្តុំព័ត៌មានត្រូវបានកាត់បន្ថយ។

នេះមានសារៈសំខាន់ជាពិសេសនៅក្នុងគ្រាទាំងនោះ នៅពេលដែលមានអ្វីមួយបានគាំងនៅកន្លែងណាមួយ ហើយរាយការណ៍យ៉ាងខឹងសម្បារអំពីវា ដើម្បីកុំឱ្យមានការរំខានទាំងស្រុងពី Elastic ហើយបន្ទាប់ពីពេលខ្លះ - ថ្នាំង Graylog ដែលមិនអាចដំណើរការបានដោយសារតែការស្ទះសតិបណ្ដោះអាសន្ន។

លើសពីនេះទៀត នៅពេលដែលយើងមានការផ្ទុះដូចគ្នានេះនៅក្នុងផលិតកម្ម យើងបានទទួលការត្អូញត្អែរពីអ្នកសរសេរកម្មវិធី និងអ្នកសាកល្បង៖ នៅពេលពួកគេពិតជាត្រូវការកំណត់ហេតុទាំងនេះ ពួកគេត្រូវបានផ្តល់ឱ្យពួកគេយឺតណាស់។

ពួកគេ​បាន​ចាប់​ផ្តើម​ស្វែង​យល់។ នៅលើដៃម្ខាង វាច្បាស់ណាស់ថាទាំងសំណួរស្វែងរក និងសំណួរធ្វើលិបិក្រមត្រូវបានដំណើរការ ជាសំខាន់នៅលើម៉ាស៊ីនរូបវន្តដូចគ្នា ហើយវិធីមួយឬផ្សេងទៀតនឹងមានការដកមួយចំនួន។

ប៉ុន្តែនេះអាចជៀសបានដោយផ្នែកដោយសារតែការពិតដែលថានៅក្នុងកំណែទីប្រាំមួយនៃ Elasticsearch ក្បួនដោះស្រាយមួយបានលេចឡើងដែលអនុញ្ញាតឱ្យអ្នកចែកចាយសំណួររវាងថ្នាំងទិន្នន័យដែលពាក់ព័ន្ធមិនយោងទៅតាមគោលការណ៍ជុំវិលជុំចៃដន្យ (កុងតឺន័រដែលធ្វើលិបិក្រមនិងផ្ទុកបឋម -shard អាចរវល់ខ្លាំង វានឹងមិនមានវិធីដើម្បីឆ្លើយតបរហ័សទេ) ប៉ុន្តែដើម្បីបញ្ជូនសំណើនេះទៅកាន់កុងតឺន័រដែលមិនសូវផ្ទុកជាមួយនឹង replica-shard ដែលនឹងឆ្លើយតបកាន់តែលឿន។ នៅក្នុងពាក្យផ្សេងទៀត យើងបានមកដល់ use_adaptive_replica_selection: true។

រូបភាពនៃការអានចាប់ផ្តើមមើលទៅដូចនេះ៖

ការផ្លាស់ប្តូរទៅក្បួនដោះស្រាយនេះបានធ្វើឱ្យវាអាចធ្វើទៅបានដើម្បីកែលម្អពេលវេលាសំណួរនៅក្នុងពេលវេលាទាំងនោះនៅពេលដែលយើងមានលំហូរធំនៃកំណត់ហេតុដើម្បីសរសេរ។

ទីបំផុតបញ្ហាចម្បងគឺការដកយកចេញដោយគ្មានការឈឺចាប់នៃមជ្ឈមណ្ឌលទិន្នន័យ។

អ្វីដែលយើងចង់បានពីចង្កោមភ្លាមៗបន្ទាប់ពីបាត់បង់ការតភ្ជាប់ជាមួយ DC មួយ៖

• ប្រសិនបើយើងមានមេបច្ចុប្បន្ននៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យដែលបរាជ័យ នោះវានឹងត្រូវបានជ្រើសរើសឡើងវិញ និងផ្លាស់ទីជាតួនាទីមួយទៅកាន់ node ផ្សេងទៀតនៅក្នុង DC ផ្សេងទៀត។
• មេនឹងលុបថ្នាំងដែលមិនអាចចូលដំណើរការទាំងអស់ចេញពីចង្កោមបានយ៉ាងលឿន។
• ដោយផ្អែកលើអ្វីដែលនៅសេសសល់ គាត់នឹងយល់៖ នៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យដែលបាត់បង់ដែលយើងមាន និងផ្នែកសំខាន់ៗបែបនេះ គាត់នឹងផ្សព្វផ្សាយ shards ចម្លងបន្ថែមយ៉ាងឆាប់រហ័សនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យដែលនៅសល់ ហើយយើងនឹងបន្តធ្វើលិបិក្រមទិន្នន័យ។
• ជាលទ្ធផល ការសរសេរ និងការអានរបស់ចង្កោមនឹងថយចុះបន្តិចម្តងៗ ប៉ុន្តែជាទូទៅអ្វីៗនឹងដំណើរការ ទោះបីជាយឺត ប៉ុន្តែមានស្ថេរភាព។

ដូចដែលវាបានប្រែក្លាយយើងចង់បានអ្វីមួយដូចនេះ:

ហើយយើងទទួលបានដូចខាងក្រោមៈ

តើរឿងនេះកើតឡើងដោយរបៀបណា?

នៅពេលដែលមជ្ឈមណ្ឌលទិន្នន័យធ្លាក់ចុះ មេរបស់យើងបានក្លាយជាអ្នករារាំង។

ហេតុអ្វី?

ការពិតគឺថាមេមាន TaskBatcher ដែលទទួលខុសត្រូវក្នុងការចែកចាយកិច្ចការ និងព្រឹត្តិការណ៍មួយចំនួននៅក្នុងចង្កោម។ ការចេញថ្នាំងណាមួយ ការផ្សព្វផ្សាយណាមួយនៃ shard ពីការចម្លងទៅបឋម កិច្ចការណាមួយដើម្បីបង្កើត shard នៅកន្លែងណាមួយ - ទាំងអស់នេះទៅមុនគេទៅកាន់ TaskBatcher ដែលជាកន្លែងដែលវាត្រូវបានដំណើរការជាបន្តបន្ទាប់ និងនៅក្នុងខ្សែស្រឡាយមួយ។

នៅពេលដកមជ្ឈមណ្ឌលទិន្នន័យមួយ វាបានប្រែក្លាយថាថ្នាំងទិន្នន័យទាំងអស់នៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យដែលនៅរស់បានចាត់ទុកថាវាជាកាតព្វកិច្ចរបស់ពួកគេក្នុងការជូនដំណឹងដល់មេថា "យើងបានបាត់បង់ឧបករណ៍ទាំងនេះ និងថ្នាំងទិន្នន័យបែបនេះ។"

ក្នុងពេលជាមួយគ្នានេះ ថ្នាំងទិន្នន័យដែលនៅរស់បានបញ្ជូនព័ត៌មានទាំងអស់នេះទៅមេបច្ចុប្បន្ន ហើយព្យាយាមរង់ចាំការបញ្ជាក់ថាគាត់ទទួលយកវា។ ពួកគេមិនរង់ចាំរឿងនេះទេ ព្រោះចៅហ្វាយបានទទួលកិច្ចការលឿនជាងគាត់អាចឆ្លើយបាន។ ថ្នាំងបានអស់ពេលអស់ពេលសំណើរដដែលៗ ហើយមេនៅពេលនេះមិនបានព្យាយាមឆ្លើយពួកគេទេ ប៉ុន្តែត្រូវបានស្រូបយកទាំងស្រុងក្នុងកិច្ចការតម្រៀបសំណើតាមអាទិភាព។

នៅក្នុងទម្រង់ស្ថានីយ វាបានប្រែក្លាយថាថ្នាំងទិន្នន័យបាន spam មេដល់ចំណុចដែលវាចូលទៅក្នុង GC ពេញលេញ។ បន្ទាប់ពីនោះ តួនាទីមេរបស់យើងបានផ្លាស់ប្តូរទៅថ្នាំងបន្ទាប់មួយចំនួន ដែលពិតជារឿងដដែលនេះបានកើតឡើងចំពោះវា ហើយជាលទ្ធផល ចង្កោមបានដួលរលំទាំងស្រុង។

យើងបានធ្វើការវាស់វែង ហើយមុនកំណែ 6.4.0 ដែលវាត្រូវបានជួសជុល វាគ្រប់គ្រាន់សម្រាប់យើងក្នុងពេលដំណាលគ្នាបញ្ចេញថ្នាំងទិន្នន័យចំនួន 10 ក្នុងចំណោម 360 ដើម្បីបិទចង្កោមទាំងស្រុង។

វាមើលទៅដូចនេះ៖

បន្ទាប់ពីកំណែ 6.4.0 ដែលកំហុសដ៏អាក្រក់នេះត្រូវបានជួសជុល ថ្នាំងទិន្នន័យឈប់សម្លាប់មេ។ ប៉ុន្តែវាមិនបានធ្វើឱ្យគាត់ "ឆ្លាតជាង" ឧទាហរណ៍៖ នៅពេលដែលយើងបញ្ចេញថ្នាំងទិន្នន័យ 2, 3 ឬ 10 (លេខណាមួយក្រៅពីមួយ) មេទទួលបានសារដំបូងមួយចំនួនដែលនិយាយថា node A បានចាកចេញ ហើយព្យាយាមប្រាប់ node B, node C អំពីវា, node D ។

ហើយនៅពេលនេះ វាអាចដោះស្រាយបានតែដោយការកំណត់ពេលវេលាសម្រាប់ការព្យាយាមប្រាប់នរណាម្នាក់អំពីអ្វីមួយ ស្មើនឹងប្រហែល 20-30 វិនាទី ហើយដូច្នេះគ្រប់គ្រងល្បឿននៃមជ្ឈមណ្ឌលទិន្នន័យដែលផ្លាស់ទីចេញពីចង្កោម។

ជាគោលការណ៍ នេះសមនឹងតម្រូវការដែលត្រូវបានបង្ហាញដំបូងចំពោះផលិតផលចុងក្រោយដែលជាផ្នែកមួយនៃគម្រោង ប៉ុន្តែតាមទស្សនៈនៃ "វិទ្យាសាស្ត្រសុទ្ធ" នេះគឺជាកំហុស។ ដែលតាមវិធីនេះត្រូវបានជួសជុលដោយជោគជ័យដោយអ្នកអភិវឌ្ឍន៍នៅក្នុងកំណែ 7.2 ។

ជាងនេះទៅទៀត នៅពេលដែលថ្នាំងទិន្នន័យជាក់លាក់មួយបានចេញទៅ វាបានប្រែក្លាយថាការផ្សព្វផ្សាយព័ត៌មានអំពីការចាកចេញរបស់វាមានសារៈសំខាន់ជាងការប្រាប់ចង្កោមទាំងមូលថាមានផ្នែកសំខាន់ៗបែបនេះនៅលើវា (ដើម្បីផ្សព្វផ្សាយការចម្លង-shard នៅក្នុងទិន្នន័យផ្សេងទៀត កណ្តាលនៅចំកណ្តាល ហើយព័ត៌មានអាចត្រូវបានសរសេរនៅលើពួកវា)។

ដូច្នេះហើយ នៅពេលដែលអ្វីៗទាំងអស់បានងាប់អស់ហើយ ថ្នាំងទិន្នន័យដែលបានចេញផ្សាយមិនត្រូវបានសម្គាល់ភ្លាមៗថាជាប់គាំងនោះទេ។ ដូច្នោះហើយ យើងបង្ខំចិត្តរង់ចាំរហូតដល់ ping ទាំងអស់អស់ពេលសម្រាប់ថ្នាំងទិន្នន័យដែលបានចេញផ្សាយ ហើយបន្ទាប់ពីនោះចង្កោមរបស់យើងចាប់ផ្តើមប្រាប់យើងថានៅទីនោះ ទីនោះ ហើយនៅទីនោះ យើងត្រូវបន្តការកត់ត្រាព័ត៌មាន។ អ្នកអាចអានបន្ថែមអំពីរឿងនេះ នៅទីនេះ.

ជាលទ្ធផល ប្រតិបត្តិការដកមជ្ឈមណ្ឌលទិន្នន័យថ្ងៃនេះ ចំណាយពេលប្រហែល 5 នាទីក្នុងម៉ោងប្រញាប់។ សម្រាប់ colossus ដ៏ធំ និងច្របូកច្របល់បែបនេះ នេះគឺជាលទ្ធផលល្អណាស់។

ជាលទ្ធផលយើងឈានដល់ការសម្រេចចិត្តដូចខាងក្រោមៈ

• យើងមានថ្នាំងទិន្នន័យ 360 ដែលមានថាស 700 ជីហ្គាបៃ។
• អ្នកសំរបសំរួលចំនួន 60 នាក់សម្រាប់កំណត់ផ្លូវចរាចរតាមរយៈថ្នាំងទិន្នន័យដូចគ្នាទាំងនេះ។
• ចៅហ្វាយនាយចំនួន 40 ដែលយើងបានបន្សល់ទុកជាមរតកមួយប្រភេទចាប់តាំងពីកំណែមុន 6.4.0 - ដើម្បីរស់រានពីការដកមជ្ឈមណ្ឌលទិន្នន័យ យើងត្រូវបានរៀបចំផ្លូវចិត្តដើម្បីបាត់បង់ម៉ាស៊ីនជាច្រើន ដើម្បីធានាឱ្យមានកូរ៉ុមចៅហ្វាយនាយសូម្បីតែនៅក្នុង សេណារីយ៉ូករណីអាក្រក់បំផុត។
• ការប៉ុនប៉ងណាមួយដើម្បីបញ្ចូលគ្នានូវតួនាទីនៅលើកុងតឺន័រមួយត្រូវបានបំពេញដោយការពិតដែលថាមិនយូរមិនឆាប់ថ្នាំងនឹងខូចនៅក្រោមបន្ទុក។
• ចង្កោមទាំងមូលប្រើ heap.size នៃ 31 ជីហ្គាបៃ៖ ការប៉ុនប៉ងទាំងអស់ដើម្បីកាត់បន្ថយទំហំបានបណ្តាលឱ្យមានការសម្លាប់ថ្នាំងមួយចំនួននៅលើសំណួរស្វែងរកដ៏ធ្ងន់ជាមួយនឹងតួអក្សរជំនួសនាំមុខ ឬទទួលបានឧបករណ៍បំបែកសៀគ្វីនៅក្នុង Elasticsearch ខ្លួនឯង។
• លើសពីនេះទៀត ដើម្បីធានាបាននូវដំណើរការស្វែងរក យើងបានព្យាយាមរក្សាចំនួនវត្ថុនៅក្នុងចង្កោមឱ្យតូចតាមដែលអាចធ្វើបាន ដើម្បីដំណើរការព្រឹត្តិការណ៍តិចតួចតាមដែលអាចធ្វើទៅបាននៅក្នុងបញ្ហាជាប់គាំងដែលយើងទទួលបាននៅក្នុងមេ។

ទីបំផុតអំពីការត្រួតពិនិត្យ

ដើម្បីធានាថាទាំងអស់នេះដំណើរការដូចបំណង យើងតាមដានដូចខាងក្រោម៖

• ថ្នាំងទិន្នន័យនីមួយៗរាយការណ៍ទៅ Cloud របស់យើងថាវាមាន ហើយមានដុំតូចៗបែបនេះនៅលើវា។ នៅពេលដែលយើងពន្លត់អ្វីមួយនៅកន្លែងណាមួយ ចង្កោមរាយការណ៍បន្ទាប់ពី 2-3 វិនាទីថានៅកណ្តាល A យើងបានពន្លត់ថ្នាំង 2, 3 និង 4 - នេះមានន័យថានៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យផ្សេងទៀតយើងមិនស្ថិតក្រោមកាលៈទេសៈណាអាចពន្លត់ថ្នាំងទាំងនោះដែលមានតែមួយ shard បានទេ។ ឆ្វេង។
• ដោយដឹងពីលក្ខណៈនៃអាកប្បកិរិយារបស់ចៅហ្វាយ យើងពិនិត្យមើលយ៉ាងយកចិត្តទុកដាក់លើចំនួនកិច្ចការដែលមិនទាន់សម្រេច។ ពីព្រោះសូម្បីតែកិច្ចការដែលជាប់គាំងមួយក៏ដោយ ប្រសិនបើវាមិនអស់ពេលទាន់ពេលទេ ទ្រឹស្តីនៅក្នុងស្ថានភាពអាសន្នមួយចំនួនអាចក្លាយជាហេតុផលដែលឧទាហរណ៍ ការផ្សព្វផ្សាយនៃ shard ចម្លងនៅក្នុងបឋមមិនដំណើរការ ដែលជាមូលហេតុដែលការបង្កើតលិបិក្រមនឹងឈប់ដំណើរការ។
• យើងក៏ពិនិត្យមើលយ៉ាងដិតដល់ផងដែរចំពោះការពន្យារពេលអ្នកប្រមូលសំរាម ពីព្រោះយើងមានការលំបាកយ៉ាងខ្លាំងជាមួយបញ្ហានេះរួចហើយ អំឡុងពេលបង្កើនប្រសិទ្ធភាព។
• ច្រាន​ចោល​តាម​ខ្សែ​ដើម្បី​យល់​ជាមុន​ពី​កន្លែង​ដែល​ស្ទះ។
• ជាការប្រសើរណាស់, ម៉ែត្រស្តង់ដារដូចជា heap, RAM និង I/O ។

នៅពេលត្រួតពិនិត្យអគារ អ្នកត្រូវតែគិតគូរពីលក្ខណៈពិសេសនៃ Thread Pool នៅក្នុង Elasticsearch ។ ឯកសារ Elasticsearch ពិពណ៌នាអំពីជម្រើសនៃការកំណត់រចនាសម្ព័ន្ធ និងតម្លៃលំនាំដើមសម្រាប់ការស្វែងរក និងការធ្វើលិបិក្រម ប៉ុន្តែនៅស្ងៀមទាំងស្រុងអំពី thread_pool.management។ ដំណើរការខ្សែស្រឡាយទាំងនេះ ជាពិសេសសំណួរដូចជា _cat/shards និងតម្លៃស្រដៀងគ្នាផ្សេងទៀត ដែលងាយស្រួលប្រើនៅពេលសរសេរការត្រួតពិនិត្យ។ ចង្កោមកាន់តែធំ សំណើបែបនេះកាន់តែច្រើនត្រូវបានប្រតិបត្តិក្នុងមួយឯកតានៃពេលវេលា ហើយ thread_pool.management ដែលបានរៀបរាប់ខាងលើមិនត្រឹមតែមិនត្រូវបានបង្ហាញនៅក្នុងឯកសារផ្លូវការប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងត្រូវបានកំណត់តាមលំនាំដើមដល់ 5 ខ្សែ ដែលត្រូវបានបោះចោលយ៉ាងឆាប់រហ័សបន្ទាប់ពី ការត្រួតពិនិត្យណាមួយឈប់ដំណើរការត្រឹមត្រូវ។

អ្វីដែលខ្ញុំចង់និយាយនៅក្នុងការសន្និដ្ឋាន: យើងបានធ្វើវា! យើងអាចផ្តល់ឱ្យអ្នកសរសេរកម្មវិធី និងអ្នកអភិវឌ្ឍន៍របស់យើងនូវឧបករណ៍មួយ ដែលស្ទើរតែគ្រប់ស្ថានភាពទាំងអស់ អាចផ្តល់ព័ត៌មានយ៉ាងឆាប់រហ័ស និងគួរឱ្យទុកចិត្តអំពីអ្វីដែលកំពុងកើតឡើងនៅក្នុងផលិតកម្ម។

បាទ វាប្រែទៅជាស្មុគស្មាញ ប៉ុន្តែទោះជាយ៉ាងណា យើងបានគ្រប់គ្រងឱ្យសមនឹងបំណងប្រាថ្នារបស់យើងទៅក្នុងផលិតផលដែលមានស្រាប់ ដែលយើងមិនចាំបាច់ជួសជុល និងសរសេរឡើងវិញសម្រាប់ខ្លួនយើង។

ប្រភព: www.habr.com