下一屆 HighLoad++ 會議將於 6 年 7 月 2020 日至 XNUMX 日在聖彼得堡舉行 詳情和門票 。 HighLoad++ 莫斯科 2018。「莫斯科」大廳。 9 月 15 日 00:XNUMX。論文和 .
* 監控 - 線上和分析。
* Zabbix平台的基本限制。
* 擴充分析儲存的解決方案。
* Zabbix伺服器的優化。
* 介面優化。
* 具有在超過 40k NVPS 負載下作業系統的經驗。
* 簡要結論。
米哈伊爾‧馬庫洛夫（以下簡稱「MM」）： - 大家好！
馬克西姆·切爾涅佐夫（以下簡稱“MCH”）： - 午安!
毫米： – 讓我來介紹一下馬克西姆。馬克斯是一位才華洋溢的工程師，也是我所認識的最好的網路專家。 Maxim 涉足網路和服務及其開發和營運。
婦幼保健院： – 我想告訴你關於米哈伊爾的事。 Mikhail 是一名 C 開發人員。他為我們公司編寫了多個高負載流量處理解決方案。我們在烏拉爾地區、車里雅賓斯克硬漢之城、Intersvyaz 公司生活和工作。我們公司是一家為 16 個城市的 XNUMX 萬人提供網路和有線電視服務的供應商。
毫米： – 值得一提的是，Intersvyaz 不僅僅是一家供應商，它還是一家 IT 公司。我們的解決方案大部分都是由我們的 IT 部門制定的。
但： 從處理流量的伺服器到呼叫中心和行動應用程式。 IT 部門現在約有 80 名員工，他們的能力非常非常多元。
關於 Zabbix 及其架構
婦幼保健院： – 現在我將嘗試創下個人記錄，在一分鐘內說出Zabbix是什麼（以下簡稱「Zabbix」）。
Zabbix將自己定位為企業級開箱即用的監控系統。它具有許多讓生活更輕鬆的功能：進階升級規則、用於整合的 API、主機和指標的分組和自動檢測。 Zabbix 有所謂的擴充工具——代理商。 Zabbix是一個開源系統。
簡單介紹一下建築。我們可以說它由三個部分組成：
- 伺服器.用C寫成。線程之間的資訊處理和傳輸相當複雜。所有處理都在其中進行：從接收到保存到資料庫。
- 所有資料都儲存在資料庫中。 Zabbix 支援 MySQL、PostreSQL 和 Oracle。
- Web 介面是用 PHP 寫的。在大多數系統上，它都配備了 Apache 伺服器，但與 nginx + php 結合使用會更有效。
今天我們想講述一個與 Zabbix 有關的我們公司生活中的故事...
Intersvyaz 公司的故事。我們擁有什麼以及我們需要什麼？
五、六個月前。一天下班後...
婦幼保健院： - 米莎，你好！我很高興能找到你——正在交談。我們又遇到了監控問題。在一次重大事故期間，一切都很慢，並且沒有有關網路狀態的資訊。不幸的是，這並不是第一次發生這種情況。我需要你的幫助。讓我們的監控在任何情況下都能發揮作用！
毫米： - 但我們首先要同步。我已經好幾年沒看過那裡了。據我記得，大約 8 年前我們放棄了 Nagios，轉而使用 Zabbix。現在我們似乎擁有 6 台強大的伺服器和大約十幾個代理程式。我混淆了什麼嗎？
婦幼保健院： - 幾乎。 15台伺服器，其中一些是虛擬機器。最重要的是它並沒有在我們最需要的時候拯救我們。就像一場意外——伺服器速度變慢，你看不到任何東西。我們嘗試優化配置，但這並沒有提供最佳的效能提升。
毫米： - 天氣晴朗。您是否查看過某些內容，是否已經從診斷中挖掘出某些內容？
婦幼保健院： – 您首先要處理的是資料庫。 MySQL 不斷加載，儲存新的指標，當 Zabbix 開始產生一堆事件時，資料庫會在幾個小時內進入超速狀態。我已經告訴過您有關優化配置的信息，但實際上今年他們更新了硬體：伺服器擁有超過 XNUMX GB 的內存和 SSD RAID 磁碟陣列 - 從長遠來看，線性增長是沒有意義的。我們做什麼？
毫米： - 天氣晴朗。一般來說，MySQL是一個LTP資料庫。顯然，它不再適合儲存我們規模的指標檔案。讓我們弄清楚一下。
婦幼保健院： - 讓我們！
黑客馬拉鬆的結果是 Zabbix 和 Clickhouse 的集成
一段時間後，我們收到了有趣的數據：
我們資料庫中的大部分空間被指標存檔佔用，不到 1% 用於配置、模板和設定。那時我們基於Clickhouse的大數據解決方案已經運作一年多了。運動的方向對我們來說是顯而易見的。在我們的春季黑客馬拉鬆上，我編寫了 Zabbix 與 Clickhouse 的伺服器和前端整合。當時Zabbix已經支援ElasticSearch，我們決定要將它們進行比較。
Clickhouse 和 Elasticsearch 的比較
毫米： – 為了進行比較，我們產生了與 Zabbix 伺服器提供的相同的負載，並觀察了系統的行為。我們使用 CURL 批量寫入數據，每行 1000 行。我們事先假設 Clickhouse 對於 Zabbix 的負載設定檔會更有效。結果甚至超出了我們的預期：
在相同的測試條件下，Clickhouse 寫入的資料是原來的三倍。同時，兩個系統在讀取資料時消耗的效率都非常高（少量資源）。但是Elastics在錄製時需要大量的處理器：
總的來說，Clickhouse 在處理器消耗和速度方面明顯優於 Elastix。同時，由於資料壓縮，Clickhouse 在硬碟上的使用量減少了 11 倍，執行的磁碟操作也減少了約 30 倍：
婦幼保健院： – 是的，Clickhouse 與磁碟子系統的配合非常有效率。您可以使用巨大的 SATA 磁碟作為資料庫，並獲得每秒數十萬行的寫入速度。開箱即用的系統支援分片、複製，並且非常易於配置。我們對它全年的使用非常滿意。
為了最佳化資源，您可以將 Clickhouse 安裝在現有主資料庫旁邊，從而節省大量 CPU 時間和磁碟操作。我們已將指標存檔移至現有的 Clickhouse 叢集：
我們大大減輕了主MySQL資料庫的負擔，以至於我們可以將其與Zabbix伺服器合併在一台機器上，並放棄MySQL的專用伺服器。
Zabbix 中的輪詢是如何運作的？
4個月前
毫米： – 好吧，我們可以忘記基地的問題嗎？
婦幼保健院： - 這是肯定的！我們需要解決的另一個問題是資料收集速度慢。現在，我們所有 15 台代理伺服器都因 SNMP 和輪詢進程而超載。而且除了安裝新的、新的伺服器之外，沒有辦法。
毫米： - 偉大的。但首先，告訴我們輪詢在 Zabbix 中是如何運作的？
婦幼保健院： – 簡而言之，指標有 20 種類型和十幾種獲取方法。 Zabbix 可以透過「請求-回應」模式收集數據，也可以透過「Trapper Interface」等待新數據。
值得注意的是，在原來的Zabbix中這個方法（Trapper）是最快的。
有代理伺服器用於負載分配：
代理程式可以執行與 Zabbix 伺服器相同的收集功能，從其接收任務並透過 Trapper 介面發送收集到的指標。這是官方推薦的負載分配方式。代理對於監控透過 NAT 或慢速通道運行的遠端基礎設施也很有用：
毫米： – 建築的一切都很清楚。我們需要查看來源...
幾天後
nmap fping 如何獲勝的故事
毫米： “我想我挖出了一些東西。”
婦幼保健院： - 告訴我！
毫米： – 我發現在檢查可用性時，Zabbix 一次最多檢查 128 個主機。我嘗試將這個數字增加到 500，並刪除 ping (ping) 中的資料包間隔 - 這會使效能翻倍。但我想要更大的數字。
婦幼保健院： – 在我的實踐中，我有時必須檢查數千台主機的可用性，而我從未見過比 nmap 更快的東西。我確信這是最快的方法。我們來試試吧！我們需要大幅增加每次迭代的主機數量。
毫米： ——查五百多？ 600？
婦幼保健院： - 至少有幾千。
毫米： - 好的。我最想說的是，我發現Zabbix中的大多數輪詢都是同步完成的。我們肯定需要將其更改為非同步模式。然後，我們可以顯著增加輪詢器收集的指標數量，特別是如果我們增加每次迭代的指標數量。
婦幼保健院： - 偉大的！什麼時候？
毫米： – 和往常一樣，昨天。
婦幼保健院： – 我們比較了 fping 和 nmap 的兩個版本：
在大量主機上，nmap 的效率預計最高可達五倍。由於 nmap 僅檢查可用性和響應時間，因此我們將損失的計算轉移到觸發器中，並顯著縮短了可用性檢查間隔。我們發現每次迭代 nmap 的最佳主機數量約為 4 個。 Nmap 讓我們能夠將可用性檢查的 CPU 成本降低三倍，並將間隔從 120 秒減少到 10 秒。
輪詢優化
毫米： 「然後我們開始做民調。我們主要對 SNMP 檢測和代理感興趣。在Zabbix中，輪詢是同步完成的，並採取了特殊措施來提高系統的效率。在同步模式下，主機無法使用會導致輪詢效能顯著下降。有一個完整的狀態系統，有特殊的進程 - 所謂的無法存取的輪詢器，僅適用於無法存取的主機：
這是一個評論，展示了狀態矩陣，以及系統保持有效所需的所有轉換系統的複雜性。另外，同步輪詢本身相當慢：
這就是為什麼數十個代理程式上的數千個輪詢器流無法為我們收集所需的資料量的原因。非同步實作不僅解決了執行緒數量的問題，而且還顯著簡化了不可用主機的狀態系統，因為對於一次輪詢迭代中檢查的任何數量，最大等待時間為 1 個逾時：
此外，我們也修改並改進了 SNMP 請求的輪詢系統。事實上，大多數人無法同時回應多個 SNMP 請求。因此，我們採用了混合模式，當同一台主機的 SNMP 輪詢是非同步完成時：
這是針對整個主機包完成的。這種模式最終並不比完全非同步的模式慢，因為輪詢 1 個 SNMP 值仍然比 XNUMX 個逾時快得多。
我們的實驗表明，使用 SNMP 輪詢時，一次迭代中的最佳請求數約為 8 個。總的來說，轉換到非同步模式使我們能夠將輪詢效能加快 200 倍、數百倍。
婦幼保健院： – 由此產生的輪詢優化表明，我們不僅可以擺脫所有代理，還可以減少許多檢查的間隔，並且不再需要代理作為分擔負載的方式。
大約三個月前
改變架構－增加負載！
毫米： - 好吧，麥克斯，是時候提高工作效率了嗎？我需要一個強大的伺服器和一個優秀的工程師。
婦幼保健院： - 好吧，我們計劃一下。現在是擺脫每秒 5 個指標的死點的時候了。
升級後的早上
婦幼保健院： - Misha，我們更新了自己，但到了早上我們又回滾了......猜猜我們達到了多少速度？
毫米： – 最多 20。
婦幼保健院： - 是的，25歲！不幸的是，我們仍處於起點。
毫米： - 為什麼？您進行過任何診斷嗎？
婦幼保健院： - 是的，當然！例如，這是一個有趣的上衣：
毫米： - 讓我們來看吧。我看到我們已經嘗試了大量的輪詢線程：
但同時，他們甚至無法回收系統的一半：
而且整體效能相當小，每秒約 4 個指標：
還有別的事嗎？
婦幼保健院： – 是的，其中一位輪詢者的 strace：
毫米： – 在這裡你可以清楚地看到輪詢過程正在等待「信號量」。這些是鎖：
婦幼保健院： - 不清楚。
毫米： – 看，這類似於一組執行緒嘗試使用一次只有一個執行緒可以使用的資源的情況。然後他們所能做的就是隨著時間的推移共享這個資源：
使用此類資源的總效能受到一個核心速度的限制：
有兩種方法可以解決這個問題。
升級機器的硬件，切換到更快的核心：
或改變架構，同時改變負載：
婦幼保健院： – 順便說一句，在測試機器上我們將使用比戰鬥機器更少的核心，但它們的每個核心頻率快 1,5 倍！
毫米： - 清除？您需要查看伺服器代碼。
Zabbix伺服器中的資料路徑
婦幼保健院： – 為了弄清楚這一點，我們開始分析資料在Zabbix伺服器內部是如何傳輸的：
很酷的圖片，對吧？讓我們一步一步看一下，或多或少地清楚一點。有負責收集資料的線程和服務：
它們透過套接字將收集到的指標傳輸到預處理器管理器，並保存在佇列中：
「預處理器管理器」將資料傳輸給其工作人員，工作人員執行預處理指令並透過相同套接字將它們傳回：
之後，預處理器管理器將它們儲存在歷史快取中：
從那裡，它們被歷史接收器獲取，歷史接收器執行相當多的功能：例如，計算觸發器、填充值緩存，以及最重要的是，在歷史存儲中保存指標。總的來說，這個過程很複雜，也很混亂。
毫米： – 我們看到的第一件事是大多數執行緒爭奪所謂的「配置快取」（儲存所有伺服器配置的記憶體區域）。負責收集資料的執行緒尤其會發生大量阻塞：
……因為配置不僅儲存指標及其參數，還儲存輪詢器從中獲取有關下一步操作的資訊的隊列。當有很多輪詢器並且其中一個阻塞配置時，其他輪詢器等待請求：
輪詢者不應發生衝突
因此，我們做的第一件事就是將隊列分成 4 個部分，並允許輪詢器在安全條件下同時阻塞這些隊列：
這消除了對配置快取的競爭，並且輪詢器的速度顯著提高。但後來我們遇到了一個事實：預處理器管理器開始累積作業佇列：
預處理器管理器必須能夠確定優先權
這種情況發生在他表現不佳的情況下。然後他所能做的就是累積來自資料收集進程的請求並將其緩衝區相加，直到耗盡所有記憶體並崩潰：
為了解決這個問題，我們增加了第二個專門用於工作人員的套接字：
因此，預處理器管理器有機會確定其工作的優先級，如果緩衝區增長，任務是減慢刪除速度，讓工作人員有機會佔用此緩衝區：
然後我們發現，速度放緩的原因之一是工人本身，因為他們正在爭奪對他們的工作完全不重要的資源。我們將此問題記錄為錯誤修復，並已在新版本的 Zabbix 中解決：
我們增加套接字數量 - 我們得到結果
此外，預處理器管理器本身也成為了一個瓶頸，因為它是一個執行緒。它依賴核心速度，最高速度約為每秒 70 個指標：
因此，我們製作了四個，具有四組插座的工人：
這使我們能夠將速度提高到大約 130 個指標：
成長的非線性可以透過歷史緩存競爭的出現來解釋。 4 名預處理器管理者和歷史沉降者爭奪它。此時，我們在測試機器上每秒接收約 130 萬個指標，大約 95% 的處理器利用了它：
大約2,5個月前
來自 snmp 社群的拒絕使 NVP 增加了一倍半
毫米： – 麥克斯，我需要一輛新的測試車！我們不再適應當前的情況。
婦幼保健院： - 你現在有什麼？
毫米： – 現在 – 130k NVP 和現成的處理器。
婦幼保健院： - 哇！涼爽的！等等，我有兩個問題。根據我的計算，我們每秒需要大約 15-20 個指標。為什麼我們需要更多？
毫米： “我想完成工作。”我想看看我們能從這個系統中榨取多少。
婦幼保健院： - 但…
毫米： “但這對商業來說毫無用處。”
婦幼保健院： - 天氣晴朗。第二個問題：我們可以在沒有開發人員幫助的情況下獨立支援我們現在擁有的東西嗎？
毫米： - 我不認為。改變配置快取的工作方式是一個問題。它會影響大多數線程的變化並且相當難以維護。最有可能的是，維護它會非常困難。
婦幼保健院： “那麼我們需要某種替代方案。”
毫米： - 有這樣一個選項。我們可以切換到快速核心，同時放棄新的鎖定係統。我們仍然會得到 60-80 個指標的表現。同時，我們可以留下所有其餘的程式碼。 Clickhouse 和非同步輪詢將會發揮作用。而且它很容易維護。
婦幼保健院： - 驚人的！我建議我們停在這裡。
優化伺服器端後，我們終於能夠將新程式碼投入生產。我們放棄了一些更改，轉而改用具有快速核心的機器並最大限度地減少程式碼更改的數量。我們還簡化了配置並儘可能消除了資料項目中的宏，因為它們引入了額外的鎖定。
例如，在我們的案例中，放棄經常在文件和範例中找到的 snmp-community 宏，可以將 NVP 進一步加速約 1,5 倍。
經過兩天的製作
刪除事件歷史彈出窗口
婦幼保健院： – Misha，我們已經使用該系統兩天了，一切正常。但只有當一切正常時！我們計劃對相當大一部分網路進行傳輸，然後我們再次用手檢查哪些內容已上線，哪些內容未上線。
毫米： - 不可能！我們檢查了一切 10 次。伺服器甚至可以立即處理完全的網路不可用。
婦幼保健院： - 是的，我了解一切：伺服器、資料庫、top、austat、日誌 - 一切都很快...但是我們查看 Web 介面，伺服器上「架子上」有一個處理器，如下所示：
毫米： - 天氣晴朗。我們來看看網路吧。我們發現，在存在大量活動事件的情況下，大多數活動小工具開始運作非常緩慢：
原因是為清單中的每個項目產生事件歷史記錄彈出視窗。因此，我們放棄了這些視窗的生成（在程式碼中註解掉了5行），這解決了我們的問題。
小部件的載入時間，即使在完全不可用的情況下，也從幾分鐘縮短到了我們可以接受的10-15秒，並且仍然可以透過點擊時間來查看歷史記錄：
下班以後。 2個月前
婦幼保健院： - 米莎，妳要走了嗎？我們得談談。
毫米： - 我不是故意的。 Zabbix 又出事了？
婦幼保健院： - 不，放鬆！我只想說：一切順利，謝謝！我有一瓶啤酒。
Zabbix高效
Zabbix是相當通用且豐富的系統和功能。它可以立即用於小型安裝，但隨著需求的增長，必須對其進行最佳化。若要儲存大量指標檔案，請使用適當的儲存：
- 您可以使用與 Elasticsearch 整合或將歷史記錄上傳到文字檔案的形式的內建工具（從版本 XNUMX 開始提供）；
- 您可以利用我們的經驗以及與 Clickhouse 的整合。
為了顯著提高收集指標的速度，可以使用非同步方法收集它們，並透過 trapper 介面傳輸到 Zabbix 伺服器；或者您可以使用補丁使 Zabbix 輪詢器非同步。
Zabbix是用C語言寫的，效率相當高。解決多個架構瓶頸可以讓您進一步提高其效能，根據我們的經驗，可以在單處理器機器上獲得超過 100 萬個指標。
相同的 Zabbix 補丁
毫米： ——我想補充幾點。整個當前報告、所有測試、數字均針對我們使用的配置給出。我們現在每秒從中獲得大約 20 個指標。如果您想了解這是否適合您，可以進行比較。今天討論的內容以補丁的形式發佈在 GitHub 上：
該補丁包括：
- 與 Clickhouse 完全整合（Zabbix 伺服器和前端）；
- 解決預處理器管理器的問題；
- 異步輪詢。
該補丁與所有版本 4 相容，包括 lts。最有可能的是，只需進行最小的更改，它就可以在 3.4 版本上運行。
感謝您的關注。
問題
觀眾提問（以下簡稱－A）：－下午好！請告訴我，您是否有計劃與 Zabbix 團隊或他們與您進行深入互動，以便這不是補丁，而是 Zabbix 的正常行為？
毫米： – 是的，我們肯定會做出一些改變。有些事情會發生，有些事情會保留在補丁中。
但： – 非常感謝您的精彩報告！請告訴我，應用補丁後，Zabbix的支援仍然存在，如何繼續更新到更高版本？補丁到4.2、5.0後可以更新Zabbix嗎？
毫米： – 關於支持我無話可說。如果我是Zabbix技術支持，我可能會說不，因為這是別人的程式碼。至於 4.2 程式碼庫，我們的立場是：“我們將與時俱進，我們將在下一個版本中更新自己。”因此，一段時間內我們將發布更新版本的補丁。我在報告中已經說過：版本變化的數量還是很小的。我認為從 3.4 到 4 的過渡大約花了我們 15 分鐘。那裡發生了一些變化，但不是很重要。
但： – 那麼您計劃支援您的補丁，並且可以在生產中安全地安裝它並在將來以某種方式接收更新？
毫米： – 我們強烈推薦它。這為我們解決了很多問題。
婦幼保健院： – 我想再次提請注意這樣一個事實，即與架構無關、與阻塞或佇列無關的變更是模組化的，它們位於單獨的模組中。即使進行微小的更改，您也可以輕鬆維護它們。
毫米： – 如果您對細節感興趣，那麼「Clickhouse」使用所謂的歷史庫。它是解開的 - 它是 Elastics 支援的副本，也就是說，它是可配置的。輪詢僅改變輪詢者。我們相信這將長期有效。
但： - 多謝。告訴我，是否有任何有關所做更改的文件？
毫米： – 文檔是一個補丁。顯然，隨著 Clickhouse 的引入，隨著新型輪詢器的引入，新的配置選項出現了。最後一張投影片的連結有一個關於如何使用它的簡短描述。
關於用 nmap 取代 fping
但： – 你最終是如何實現這個的？您能舉出具體的例子嗎：您有捆綁器和外部腳本嗎？是什麼導致如此快速地檢查如此大量的主機？你如何挖掘這些主機？我們是否需要以某種方式將它們提供給 nmap，從某個地方獲取它們，將它們放入，運行一些東西？...
毫米： - 涼爽的。非常正確的一個問題！重點是這個。我們修改了用於 ICMP 檢查的庫（ICMP ping，Zabbix 的一部分），它指示封包的數量 - 一 (1)，並且程式碼嘗試使用 nmap。也就是說，這是Zabbix的內部工作，變成了pinger的內部工作。因此，不需要同步或使用捕獲器。這是故意這樣做的，以便使系統保持完整，並且不必同步兩個資料庫系統：要檢查什麼，透過輪詢器上傳，以及我們的上傳是否損壞？..這要簡單得多。
但： – 它也適用於代理商嗎？
毫米： – 是的，但我們沒有檢查。 Zabbix 和伺服器中的輪詢程式碼是相同的。應該管用。讓我再次強調：系統的效能使我們不需要代理。
婦幼保健院： – 問題的正確答案是：“為什麼需要具有這樣系統的代理？”只是因為 NAT 或透過某種慢速通道進行監控...
但： – 如果我理解正確的話，你使用 Zabbix 作為警報器。或將您的圖形（存檔層所在的位置）移動到另一個系統，例如 Grafana？還是你沒有使用這個功能？
毫米： ——我再次強調：我們已經實現了徹底的融合。我們正在將歷史注入 Clickhouse，但同時我們也更改了 php 前端。 Php 前端前往 Clickhouse 並從那裡處理所有圖形。同時，說實話，我們有一部分可以從同一個 Clickhouse、同一個 Zabbix 資料在其他圖形顯示系統中建立資料。
婦幼保健院： – 也在「格拉凡」中。
資源分配決策是如何做出的？
但： – 分享一些你的內部廚房。如何決定需要分配資源來認真加工產品？一般來說，這些是某些風險。請告訴我，在您將支持新版本這一事實的背景下：從管理的角度來看，這個決定如何證明是合理的？
毫米： – 顯然，我們沒有很好地講述歷史的戲劇。我們發現自己處於必須採取行動的境地，我們基本上與兩個平行的團隊一起進行：
- 其中一個是使用新方法啟動監控系統：監控即服務，這是一組標準的開源解決方案，我們將其組合起來，然後嘗試更改業務流程，以便與新的監控系統配合使用。
- 同時，我們有一位熱心的程式設計師正在做這件事（關於他自己）。碰巧他贏了。
但： – 團隊規模有多大？
婦幼保健院： - 她就在你面前。
但： – 所以，一如既往，你需要一個熱情的人嗎？
毫米： ——我不知道什麼是激情。
但： - 在這種情況下，顯然是你。非常感謝你，你太棒了。
毫米： - 謝謝。
關於 Zabbix 的補丁
但： – 對於使用代理程式的系統（例如，在某些分散式系統中），是否可以調整和修補，例如輪詢器、代理以及 Zabbix 本身的部分預處理器；以及他們的互動？是否可以優化具有多個代理程式的系統的現有開發？
毫米： – 我知道Zabbix伺服器是使用代理組裝的（程式碼編譯取得）。我們尚未在生產中對此進行測試。我對此不確定，但我認為代理程式中未使用預處理器管理器。代理程式的任務是從 Zabbix 取得一組指標，合併它們（它還記錄配置、本機資料庫）並將其傳回給 Zabbix 伺服器。伺服器收到資料後會自行進行預處理。
對代理的興趣是可以理解的。我們會檢查一下。這是一個有趣的話題。
但： – 這個想法是這樣的：如果你可以修補輪詢器，你就可以在代理上修補它們並修補與伺服器的交互，並僅在伺服器上調整預處理器以實現這些目的。
毫米： – 我認為這更簡單。您取得程式碼，套用補丁，然後按照您需要的方式進行設定 - 收集代理伺服器（例如，使用 ODBC）並跨系統分發修補後的程式碼。必要時 - 收集代理，必要時 - 伺服器。
但： – 最有可能的是，您不必另外修補到伺服器的代理傳輸？
婦幼保健院： - 不，這是標準的。
毫米： ——事實上，其中一個想法並不聽起來像。我們始終在想法的爆發與變化的數量以及支持的便利性之間保持平衡。
一些廣告🙂
感謝您與我們在一起。 你喜歡我們的文章嗎？ 想看更多有趣的內容？ 通過下訂單或推薦給朋友來支持我們， , 我們為您發明的入門級服務器的獨特模擬： （適用於 RAID1 和 RAID10，最多 24 個內核和最多 40GB DDR4）。
Dell R730xd 在阿姆斯特丹的 Equinix Tier IV 數據中心便宜 2 倍？ 只有這裡 在荷蘭！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 美元起！ 閱讀
來源： www.habr.com