Недостаточно свободной памяти и множество пустых индексов с использованием пула буферов в MySQL

Question

Недостаточно свободной памяти и множество пустых индексов с использованием пула буферов в MySQL

Скажем, мы работаем с этим нелепым примером:

DF <- data.frame(Class=1:10,A=1:10,B=1:10,C=1:10)

Затем вы получаете имена столбцов

Cols <- names(DF)
Cols <- Cols[! Cols %in% "Class"]
n <- length(Cols)

Вы строите все возможные комбинации

id <- unlist(
        lapply(1:n,
              function(i)combn(1:n,i,simplify=FALSE)
        )
      ,recursive=FALSE)

Вы вставляете их в формулы

Formulas <- sapply(id,function(i)
              paste("Class~",paste(Cols[i],collapse="+"))
            )

И вы перебираете их для применения моделей.

lapply(Formulas,function(i)
    lm(as.formula(i),data=DF))

Будьте осторожны: если у вас больше нескольких колонок, это быстро станет очень тяжелым для памяти и приведет к буквально тысячам моделей. У вас есть 2 ^ n - 1 разные модели, n - число столбцов.

Убедитесь, что это то, что вы хотите, в целом такого рода сравнение моделей настоятельно рекомендуется. Забудьте о любых выводах, когда вы это сделаете.

0

mysql innodb rds

задан Ricardo A 18 January 2019 в 15:44

2 ответа

Другие вопросы по тегам:

mysql innodb rds

Похожие вопросы:

score 0 · Answer 1

https://dev.mysql.com/doc/refman/8.0/en/innodb-buffer-page-table.html говорит:

TABLE_NAME [115 ]
Название таблицы, к которой принадлежит страница. Этот столбец применим только к страницам со значением PAGE_TYPE, равным INDEX.

То же самое относится к столбцу INDEX_NAME.

Попробуйте этот запрос, чтобы получить больше информации:
select page_type, page_state, table_name, index_name, 
  count(*) as Page_Count, sum(data_size)/1024/1024 as Size_in_MB 
from information_schema.innodb_buffer_page 
group by page_type, page_state, table_name, index_name 
order by Size_in_MB desc;
Я вижу на вашем снимке экрана, что многие страницы пула буферов типа INDEX по-прежнему показывают NULL для имен таблиц и индексов. [ 119] 1110 Я не уверен, что это значит. Я посмотрел исходный код MySQL, и кажется, что он может оставить эти значения как NULL, если не может найти индекс в словаре данных InnoDB. Но я не уверен, как это могло произойти.

https://github.com/mysql/mysql-server/blob/5.6/storage/innobase/handler/i_s.cc#L5007

Комментарий от @C GK:

Да, вы правы, я проверил, и я вижу разницу. Я полагаю, что разница показывает коэффициент заполнения страниц.
select page_type, page_state, table_name, index_name,
  count(*) as Page_Count,
  count(*) * @@innodb_page_size /1024/1024 AS Total_Page_Size_in_MB,
  sum(data_size)/1024/1024 as Size_in_MB
from information_schema.innodb_buffer_page  
group by page_type, page_state, table_name, index_name
order by Size_in_MB desc

+-------------------+------------+--------------+------------+------------+-----------------------+-------------+
| page_type         | page_state | table_name   | index_name | Page_Count | Total_Page_Size_in_MB | Size_in_MB  |
+-------------------+------------+--------------+------------+------------+-----------------------+-------------+
| INDEX             | FILE_PAGE  | `test`.`foo` | PRIMARY    |       1940 |           30.31250000 | 27.87315369 |

score 0 · Answer 2

Есть ли проблема? Когда MySQL работает, ему обычно выделяется весь buffer_pool.

5.7 buffer_pool
x.x various other tables and caches
y.y code (OS, MySQL, etc)
0.6 "freeable" memory
---
7.5 Total

600 МБ находится под управлением ОС, а не MySQL. Вероятно, это будут дисковые блоки, которые кэшируются в оперативной памяти. Если они соответствуют тому, что находится на диске (то есть не "грязно"), то они сразу же могут быть использованы повторно.

3.7 ГБ, которые вы показываете в этой таблице , могут быть свободными блоками под контролем InnoDB. Если это так, они будут использованы повторно, когда вы сделаете INSERTs и т. Д.

(Предостережение: большая часть этого ответа - «угадывание», основываясь на моем опыте.)