Собираются ли переходные мусор?

Этот вопрос заставил меня думать Переходные RSS-каналы в wp_options не удаляется автоматически?

Срок действия переходных процессов истекает и должен быть удален. Однако единственный способ, которым я вижу, что это обрабатывается, заключается в том, что переходный период истекает и запрашивается, затем он удаляется во время запроса.

Что делать, если переходный период истек, но не запрашивается после этого? Из описания в Codex я думал, что подразумевается какая-то сборка мусора. Теперь я не уверен и не могу найти код, который выполняет такие функции.

Так будет ли это просто застрять в базе данных навсегда?

58 голосов | спросил Rarst 9 Jam1000000amSun, 09 Jan 2011 03:20:17 +030011 2011, 03:20:17

3 ответа


42

Теперь они

Начиная с WordPress 3.7 истекшие переходные процессы удаляются при обновлении базы данных, см. # 20316


Старый ответ

Если кто-то не может показать мне иначе, кажется, что переходные процессы не являются мусором, собранным в конце концов. Хуже то, что в отличие от опций они не гарантируются в базе данных. Таким образом, нет надежного способа получить список всех переходных процессов, чтобы проверить их на срок действия.

Некоторые временные коды для сбора мусора, если база данных используется для хранения:

add_action ('wp_scheduled_delete', 'delete_expired_db_transients');

function delete_expired_db_transients () {

    глобальный $ wpdb, $ _wp_using_ext_object_cache;

    if ($ _wp_using_ext_object_cache)
        вернуть;

    $ time = isset ($ _SERVER ['REQUEST_TIME'])? (int) $ _ SERVER ['REQUEST_TIME']: time ();
    $ expired = $ wpdb-> get_col ("SELECT option_name FROM {$ wpdb-> options} WHERE option_name LIKE '_transient_timeout%' AND option_value <{$ time};");

    foreach ($ expired as $ transient) {

        $ key = str_replace ('_ transient_timeout_', '', $ transient);
        delete_transient ($ ключ);
    }
}
ответил Rarst 10 Jpm1000000pmMon, 10 Jan 2011 12:55:47 +030011 2011, 12:55:47
20

Перемещение некоторых комментариев из обсуждения в ответ с повторной формулировкой и повторным форматированием.

В принципе, все сводится к тому, что, если у вас нет сверхприбыльного случая, им действительно не нужно «собирать мусор». Если вы их никогда не забираете, то не имеет значения, есть они там или нет.

См., переходные процессы сохраняются в таблице опций по умолчанию. В базовой установке таблица опций будет содержать, пожалуй, 100 записей. Каждый переходный процесс добавляет еще две записи, но даже если у вас тысячи, они не влияют на скорость сайта, поскольку они не загружаются автоматически.

При запуске WordPress загружает параметры в память, но он загружает только опции, в которых включен флаг автозагрузки. Переходные процессы не получают этого, и поэтому не загружаются в память. Только переходные процессы, которые фактически используются позже, будут нести расходы.

С точки зрения базы данных таблица опций имеет индексы как для идентификатора параметра, так и для имени опции. Переходные процессы всегда загружаются на основе имени (ключа), поэтому поиск для них всегда является простым выбором по одному уникальному значению ключа. Таким образом, поиск является O (log (n)) и является супер быстрым. С Big-O журнала (n) вам нужно будет попасть в миллионы и миллионы строк, прежде чем он станет заметным. Честно говоря, накладные расходы при настройке и отрыве запроса вместе с фактической передачей данных являются более длительными. Сам запрос выполняется в сравнении с нулевым временем. Поэтому просто с лишними неиспользуемыми строками не влияет ни на что, кроме использования дополнительного дискового пространства.

Индексирование в базах данных является одним из тех глубоко читаемых идей, которые не имеют смысла для людей, которые на самом деле не понимали, что происходит за кулисами. Базы данных предназначены для быстрого поиска данных, с нуля, и могут справиться с такими вещами без проблем. Это довольно хорошо читается: http://en.wikipedia.org/wiki/Index_(database )

Теперь очистка наиболее очевидным способом (вызов SQL DELETE на них) фактически не удаляет их из базы данных. Он просто удаляет их из индекса и маркирует строку как «удаленную». Опять же, именно так работают базы данных. Чтобы на самом деле очистить дисковое пространство, вы должны продолжить работу и затем выполнить OPTIMIZE TABLE, и это не является быстрой операцией. Это займет время. Вероятно, больше времени, чем стоит. Этого, вероятно, недостаточно, чтобы дать вам экономию времени процессора, в общей сложности.

Если у вас есть случай, который вызывает постоянную вставку новых переходных процессов, которые не используются, тогда вам нужно найти основную проблему. Что вставляет эти переходные процессы? Используют ли они изменяющийся или мутирующий ключ? Если это так, то плагин или код, вызывающий это, должны быть исправлены, в основном, не делать этого. Это будет более полезно, потому что вполне вероятно, что код, который их не создает должным образом, также не извлекает их и, следовательно, делает больше работы, чем он должен делать.

С другой стороны, может быть случай, когда переходные процессы создаются для чего-то вроде каждого сообщения. Это действительно может быть совершенно приемлемым. Я делаю это сам в SFC, чтобы хранить входящие комментарии от Facebook. У каждого сообщения есть потенциальный переходный процесс, связанный с ним, что означает две дополнительные строки на сообщение. Если у вас есть 10k сообщений, у вас будет 20k строк в таблице опций (в конце концов). Это неплохо или медленно, потому что опять-таки очень мало различий между 100 строками и 20 000 строк, насколько это реально. Все индексируется. Это быстро, как черт. Суб-суб-миллисекунды.

Когда вы начнете получать строки million , тогда я буду волноваться. Когда размер таблицы опций увеличивается выше сотен мегабайт, тогда я был бы достаточно заинтересован, чтобы взглянуть более внимательно. Но, вообще говоря, это не проблема, кроме крайних случаев. Это, конечно, не проблема для чего-то меньшего, чем нечто вроде большого новостного сайта, сотен тысяч сообщений. И для любого сайта, достаточно большого для того, чтобы это было проблемой, вы должны использовать внешний кеш-объект какого-либо типа, а в случае , переходные процессы автоматически сохраняются там, а не в базе данных.

ответил Otto 12 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 12 Sep 2011 22:09:10 +0400 2011, 22:09:10
17

Отто - я больше не мог с вами не согласиться. Проблема в том, что в конечном итоге со всеми этими переходными процессами размер таблицы становится смешным. Это не займет миллионы строк. В настоящее время я имею дело с таблицей опций, которая имеет более 130 тыс. Строк и регулярно зависает. Поскольку поле значений представляет собой большой текстовый тип, даже поиск только строк «автозагрузки» становится кошмаром производительности. Эти поля значений хранятся отдельно от остальных данных строки. Несмотря на то, что это логически является частью одной и той же таблицы, должны выполняться соединения, чтобы вытащить нужные строки. Соединения, которые теперь берут навсегда, потому что данные, которые вам нужны, распространяются по всему месту на диске. Профилирование (используя прокси-сервер для mysql) доказало это.

Добавление автозагрузки к кластерному ключу может помочь решить эту проблему. Например, кластеризация на Autoload Desc, ID ASC, позволит всем строкам автозагрузки сначала собираться вместе на диске. Еще я думаю, что вы смотрите на огромную нагрузку с точки зрения БД.

Лично я думаю, что дизайн этой системы ужасен. Кажется, что таблица опций превратилась в общую уловку для многих вещей. Это прекрасно, если поле значений достаточно мало, чтобы быть включенным на ту же страницу, что и остальные строки, и может быть эффективно проиндексировано. К сожалению, это не так. Тот, кто его разработал, должен вернуться к классу DB101.

ответил myke 2 FriEurope/Moscow2011-12-02T23:43:05+04:00Europe/Moscow12bEurope/MoscowFri, 02 Dec 2011 23:43:05 +0400 2011, 23:43:05

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

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132