MySQL 5.7.21 將分區寫入磁碟後未釋放記憶體

我一直在測試使用 SELECT * 從 MySQL 5.7.21 和 5.7.22 的分區表中的分區中提取我沒有想法並且撞到牆上。目標是將數據寫入 S3 以供其他應用使用。

感謝您提供任何回饋，如果您需要更多資訊，請告訴我。

TL;DR 如果發生足夠的提取（選擇 * 到 OS 文件），伺服器上的記憶體永遠不會恢復並最終掛起。

筆記：

1. 每個表使用 innodb 文件，並且在 /etc/limits.conf 中對 mysql 沒有限制（/proc/pid/limits 下面列出）
2. 這是一個專門為這個提取測試而啟動的伺服器。
3. 伺服器是針對記憶體優化的雲 EC2 r4.2xlarge 61GB 4VCPU。
4. 最初 my.cnf 設置與我們沒有這種載入模式的生產環境相同（因為它是新的）

在我的搜尋中，我發現了一些關於如何調整失速方面的相互矛盾的建議。我不認為這是拖延行為，因為記憶體永遠不會被回收。

使用 grep Mem /proc/meminfo, top in batch mode, iostat, netstat -i 從整體上查看系統我排除了磁碟、網路流量飽和、寫入磁碟的文件大小。

我把它縮小到只是記憶問題。

我可以始終如一

1. 停止mysql，重新啟動它並完全分配記憶體。
2. 從大或小分區或多個系列中提取數據到 OS 文件（這些測試沒有二進制日誌記錄，輸出沒有壓縮）
3. 在將足夠的分區寫入磁碟後，我會在系統掛起“無法分叉”之前將資訊發送到作業系統的標準輸出
4. 重新啟動伺服器可以釋放記憶體，並且可以從停止的地方再次重播提取過程。
5. CPU 可以通過更大的提取（超過 10G）達到 100%，並且系統不會在 CPU 上停止。
6. 提取後刷新表沒有影響。並且參數調整沒有影響（沒有正確的組合/不知道什麼組合起作用）
7. 正常執行時間顯示負載在 5、10、15 分鐘間隔內永遠不會超過 2
8. status 命令報告打開表永遠不會超過 500 並且打開文件限制為 5K

來自工作台的性能模式報告指出它在執行時的前 5% 中。並且它正在該分區上執行 FTS。

    Query, Full Table Scan, Executed (#), Errors (#), Warnings (#),
      Total Time, Maximum Time, Avg Time, Rows Sent (#),
      Avg. Rows Sent (#), Rows Scanned (#), Avg. Rows Scanned (#), Digest
    SELECT  *
   FROM  `schema` . `partitioned_table` PARTITION ( `date_partition` ) ,
       *, 1, 0, 0, 267744528.92, 267744528.92, 267744528.92,
       7446849, 7446849.0, 7446849, 7446849.0, fcb788d6ea76c986d767b282efa1ca11

我查看了MySQL 沒有釋放記憶體，並且一些 MySQL 報告了錯誤。

/proc/(pid_of_mysqld)/limits 上的限制

cat /proc/30613/limits

  Limit                     Soft Limit           Hard Limit           Units
  Max cpu time              unlimited            unlimited            seconds
  Max file size             unlimited            unlimited            bytes
  Max data size             unlimited            unlimited            bytes
  Max stack size            8388608              unlimited            bytes
  Max core file size        0                    unlimited            bytes
  Max resident set          unlimited            unlimited            bytes
  Max processes             245523               245523               processes
  Max open files            5000                 5000                 files
  Max locked memory         65536                65536                bytes
  Max address space         unlimited            unlimited            bytes
  Max file locks            unlimited            unlimited            locks
  Max pending signals       245523               245523               signals
  Max msgqueue size         819200               819200               bytes
  Max nice priority         0                    0
  Max realtime priority     0                    0
  Max realtime timeout      unlimited            unlimited            us

mysql_safe 程序的限制

cat /proc/30023/limits

   Limit                     Soft Limit           Hard Limit           Units
   Max cpu time              unlimited            unlimited            seconds
   Max file size             unlimited            unlimited            bytes
   Max data size             unlimited            unlimited            bytes
   Max stack size            8388608              unlimited            bytes
   Max core file size        0                    unlimited            bytes
   Max resident set          unlimited            unlimited            bytes
   Max processes             245523               245523               processes
   Max open files            1024                 4096                 files
   Max locked memory         65536                65536                bytes
   Max address space         unlimited            unlimited            bytes
   Max file locks            unlimited            unlimited            locks
   Max pending signals       245523               245523               signals
   Max msgqueue size         819200               819200               bytes
   Max nice priority         0                    0
   Max realtime priority     0                    0
   Max realtime timeout      unlimited            unlimited            us

查看 /proc/meminfo 在允許掛起清理之前在最低點進行比較（下面顯示了值處於最低點時的差異 - 不是 /proc/meminfo 的整個列表）

grep -Fxvf lowest_meminfo clean_meminfo

   MemFree:        27793236 kB
   MemAvailable:   54872272 kB
   Buffers:           71980 kB
   Cached:         27404904 kB
   Active:         11688912 kB
   Inactive:       22872372 kB
   Active(anon):    7084432 kB
   Active(file):    4604480 kB
   Inactive(file): 22872320 kB
   Dirty:                24 kB
   AnonPages:       7084488 kB
   Mapped:            41360 kB
   Slab:             335776 kB
   SReclaimable:     309948 kB
   SUnreclaim:        25828 kB
   KernelStack:        3792 kB
   PageTables:        21028 kB
   Committed_AS:   55038256 kB

此系統和其他 prod 系統上的錯誤日誌在提取、mysqldump 或載入 outfile/infile 時已註意到這一點；這導致了我關於拖延的文章。

  [Note] InnoDB: page_cleaner: 1000ms intended loop took 11681ms. The settings might not be optimal.

在這種情況下發生的事情是 /etc/my.cnf 文件在

$$ client $$ 部分。 使用 meminfo、iostat、netstat、top.、uptime 和 while 循環來查看正在寫入磁碟的文件的時間戳——我注意到文件只會在提取過程的最後寫入磁碟。

文件系統 ext4 也不在其中，因為 iostat 沒有顯示出它很難固定。

儘管記憶體仍然因此而下降。讀入記憶體以寫入磁碟的數量被緩衝（分塊），結果是系統可以處理多個千兆字節大小的輸出文件。

PARTITIONs這是一張桌子上沒有很多東西的眾多原因之一。這張桌子有幾張？50 是一個“合理”的限制。無論如何，請提供SHOW CREATE TABLE。

威爾遜要求的SHOWs也將有助於找出問題。我懷疑這將是 3 個表記憶體設置之一。

（獲得更多資訊後，此答案“待續”。）

引用自：https://dba.stackexchange.com/questions/211924