У меня две установки: одна работает на Windows 10 (раздел ntfs), другая на Debian (раздел ext4). Исходный код R тот же самый. Основной процесс запускает 8 дочерних процессов (P-SOCKS) -- на 8 vcores -- которые все запрашивают и пишут в одну и ту же базу данных sqlite с поддержкой WAL.
На Windows 10 я получаю 100% загрузки ЦП, распределенной по всем процессам. На Debian я едва получаю 25% загрузки ЦП. Мониторинг процессов на Debian Я думаю, что записи являются узкими местами, так как я вижу, что только один процесс достигает 100% на своем vcore за раз. (Остальные, вероятно, ждут записи.)
Каждое соединение использует PRAGMA busy_timeout = 60000;и PRAGMA journal_mode = WAL;.
Я пытаюсь отладить это. Я пытался PRAGMA synchronous = OFF;думать, что это может быть связано с fsync(), но я не вижу никаких улучшений. Есть ли еще какие-нибудь предложения о том, что может быть причиной низкой производительности в Debian?
Редактировать:
Похоже, что Write-Cache включен на диске SCSI (проверено с помощью sdparm), а настройка параметров монтирования ext4, таких как barrier=0и , data=writebackпохоже, не дает никакого эффекта.
Бенчмаркинг
Вот простой код для сравнительного анализа параллельных записей:
make.con <- function() {
con <<- DBI::dbConnect(RSQLite::SQLite(), dbname = 'db.sqlite')
DBI::dbExecute(con, 'PRAGMA journal_mode = WAL;')
DBI::dbExecute(con, 'PRAGMA busy_timeout = 60000;')
DBI::dbExecute(con, '
CREATE TABLE IF NOT EXISTS tmp (
id INTEGER NOT NULL,
blob BLOB NOT NULL,
PRIMARY KEY (id)
)')
}
make.con()
fn <- function(x) {
set.seed(x)
# read
random.blob.read <- RSQLite::dbGetQuery(con, 'SELECT blob FROM tmp WHERE id = (SELECT abs(random() % max(tm.id)) FROM tmp tm);')
# write
blob <- serialize(list(rand = runif(1000)), connection = NULL, xdr = FALSE)
RSQLite::dbExecute(con, 'INSERT INTO tmp (blob) VALUES (:blob);', params = list('blob' = list(blob)))
}
n <- 30000L
parallel::setDefaultCluster(parallel::makeCluster(spec = 2L))
parallel::clusterExport(varlist = 'make.con')
invisible(parallel::clusterEvalQ(expr = {make.con()}))
microbenchmark::microbenchmark(
lapply(1:n, fn),
parallel::parLapplyLB(X = 1:n, fun = fn, chunk.size = 50L),
times = 2L
)
parallel::stopCluster(cl = parallel::getDefaultCluster())
Код просто считывает и записывает BLOB-объекты в базу данных. Сначала выполните несколько фиктивных запусков и дайте базе данных увеличиться до нескольких ГБ.
На моем ноутбуке с Windows 10 я получаю следующие результаты (база данных 6 ГБ):
Unit: seconds
expr min lq mean median uq max neval
lapply(1:n, fn) 26.02392 26.02392 26.54853 26.54853 27.07314 27.07314 2
parallel::parLapplyLB(X = 1:n, fun = fn, chunk.size = 50L) 15.73851 15.73851 16.44554 16.44554 17.15257 17.15257 2
Ясно вижу 1 vcore на 100%, затем 2 vcore на 100%. Производительность почти в два раза выше, что показывает, что 2 параллельных процесса не блокируют друг друга.
На Debian я получаю это:
Unit: seconds
expr min lq mean median uq max neval
lapply(1:n, fn) 39.96850 39.96850 40.14782 40.14782 40.32714 40.32714 2
parallel::parLapplyLB(X = 1:n, fun = fn, chunk.size = 50L) 43.34628 43.34628 44.85910 44.85910 46.37191 46.37191 2
Два vcore никогда не достигают максимума. Кроме того, нет никакого улучшения производительности при использовании 2 процессов — все даже хуже, поскольку они, кажется, блокируют друг друга. И, наконец, Debian работает на лучшем (хотя и виртуализированном) оборудовании.
решение1
Проверено на Ubuntu 18.04, на Windows не тестировалось.
Я упростил ваш пример и добавил код инструментирования. Первый график показывает количество записанных BLOB-объектов для каждого подпроцесса. На первом графике плато указывают на бездействие всех ядер в течение примерно 0,2 секунды, а крутые подъемы — на пакетную запись по всем ядрам. Второй график показывает необработанные данные, наиболее полезные с plotly, который не работает в ответе StackOverflow.
Включение этой функции gc()удлиняет пробеги, но распределяет нагрузку более равномерно, второй график ниже.
Я понятия не имею, что происходит. Можете ли вы повторить и поэкспериментировать с этой настройкой дальше? Я был бы признателен за обратную связь здесь или, возможно, в системе отслеживания ошибок RSQLite.
Базовый пробег, безgc()
make.con <- function() {
options(digits.secs = 6)
con <<- DBI::dbConnect(RSQLite::SQLite(), dbname = "db.sqlite")
DBI::dbExecute(con, "PRAGMA journal_mode = WAL;")
DBI::dbExecute(con, "PRAGMA busy_timeout = 60000;")
DBI::dbExecute(con, "PRAGMA synchronous = OFF;")
DBI::dbExecute(con, "
CREATE TABLE IF NOT EXISTS tmp (
id INTEGER NOT NULL,
blob BLOB NOT NULL,
PRIMARY KEY (id)
)")
}
make.con()
#> [1] 0
blob <- serialize(list(rand = runif(1000)), connection = NULL, xdr = FALSE)
fn <- function(x) {
time0 <- Sys.time()
rs <- DBI::dbSendQuery(con, "INSERT INTO tmp (blob) VALUES (:blob);")
time1 <- Sys.time()
DBI::dbBind(rs, params = list("blob" = list(blob)))
time2 <- Sys.time()
DBI::dbClearResult(rs)
time3 <- Sys.time()
# gc()
time4 <- Sys.time()
list(pid = unix::getpid(), time0 = time0, time1 = time1, time2 = time2, time3 = time3, time4 = time4)
}
n <- 1000L
parallel::setDefaultCluster(parallel::makeCluster(8L))
parallel::clusterExport(varlist = c("make.con", "blob"))
invisible(parallel::clusterEvalQ(expr = {
make.con()
}))
data <- parallel::parLapply(X = 1:n, fun = fn, chunk.size = 50L)
parallel::stopCluster(cl = parallel::getDefaultCluster())
library(tidyverse)
tbl <-
data %>%
transpose() %>%
map(unlist, recursive = FALSE) %>%
as_tibble() %>%
rowid_to_column() %>%
pivot_longer(-c(rowid, pid), names_to = "step", values_to = "time") %>%
mutate(time = as.POSIXct(time, origin = "1970-01-01")) %>%
mutate(pid = factor(pid)) %>%
arrange(time)
tbl %>%
group_by(pid) %>%
mutate(cum = row_number()) %>%
ungroup() %>%
ggplot(aes(x = time, y = cum, color = pid)) +
geom_line()
p <-
tbl %>%
ggplot(aes(x = time, y = factor(pid), group = 1)) +
geom_path() +
geom_point(aes(color = step))
p
plotly::ggplotly(p)
(Plotly не работает на StackOverflow)
Создано 2020-01-30 пользователемпакет репрекс(v0.3.0)
Результаты сgc()
