-

Fri, 07 Aug 2020 12:22:38 +0300

blue@social.macaw.me

!Русская Hubzilla Решил проанализировать свою базу, понял, что лвиная доля базы занята хабзиллой, порядка 55 ГБ. Отсюда вопрос - как бы чуть чуть скинуть вес? Может быть есть какие-нибудь скрипты чистящие устаревшие объекты или что-нибудь в настройках? Мне не очень критично, просто стало любопытно

show all 39 comments

Fri, 07 Aug 2020 12:30:56 +0300

Max Kostikov

kostikov@tiksi.net

В /admin/site есть настройки хранения импортированного контента.
Можете также вынести из базы на диск хранимые там фото (кроме профилей) используя util/storageconv.
Свой контент можно удалить только удалением канала либо работой с базой в ручном режиме (не рекомендовал бы без должного понимания).

Fri, 07 Aug 2020 12:37:37 +0300

Blue

blue@social.macaw.me

@Max Kostikov Благодарю. Уменьшил "Expiration period in days for imported (grid/network) content" с 90 до 30, оно же теперь само как-нибудь подчистится?

Fri, 07 Aug 2020 13:25:07 +0300

Max Kostikov

kostikov@tiksi.net

@Blue Да, очистится. Там различные периоды для различных очисток, но это, если я не ошибаюсь, запускается раз в сутки.

Fri, 07 Aug 2020 22:32:53 +0300 last edited: Sat, 08 Aug 2020 01:14:44 +0300

ivan zlax

zlax@ussr.win

@Blue ещё может потребоваться выполнить sql команду OPTIMIZE TABLE item;
- чтобы очистка сказалась на свободном месте сервера базы данных.
Замечу, что если используется innodb - требуется чтобы было примерно столько же свободного пространства сколько занимает таблица item (он не поддерживает оптимизацию, делает копию таблицы), если myISAM - то сможет без копии.
https://hubzilla.eu/display/45c5ef05a149c3fbe55076f416e22a5d3c3f62ea485470e23a31f6e7fd7edb70@hubzilla.eu
С этой проблемой, как я понимаю, сталкиваются рано или поздно многие администраторы хабзиллы. Рекомендую обратить внимание на базу, перед тем как она займёт более половины свободного пространства на разделе с /var/lib/mysql

Fri, 07 Aug 2020 22:50:50 +0300

Max Kostikov

kostikov@tiksi.net

@ivan zlax вы дали хороший совет как не следует делать, если вы не понимаете структуру базы данных.
Вы удалите данные из таблицы публикаций и оставите, теперь уже насовсем, связанные данные в других таблицах.

Sat, 08 Aug 2020 01:28:10 +0300 last edited: Sat, 08 Aug 2020 01:53:36 +0300

ivan zlax

zlax@ussr.win

@Max Kostikov

вы дали хороший совет как не следует делать, если вы не понимаете структуру базы данных.

Исправил комментарий, убрал ту часть, что касается структуры - это, если не ошибаюсь, Майк как-то посоветовал:

DELETE FROM item WHERE item_deleted = 1 LIMIT 500000;
DELETE FROM item WHERE item_pending_remove = 1 LIMIT 500000;

В issue на git, кажется, ещё около когда назад посоветовал. Вот слушай его потом после этого (у меня эта часть в кроне присутствовала).

Но что касается оптимизации таблицы item:
OPTIMIZE TABLE item;
лично мне это помогло освободить 5гб места (c 7,5 до 2,5ГБ уменшился соответствующий файл).

Ради инетереса попробовал ту же операцию с другими большими таблицами, в результате решил оптимизировать всю базу:
mysqlcheck -o hubzilladatabasename
В результате у меня база данных уменьшилась с 17 до 9,5ГБ. Таблица photo менее всего оптимизировалась, почти не уменьшилась (5ГБ).

Sat, 08 Aug 2020 11:34:00 +0300

Blue

blue@social.macaw.me

@ivan zlax удаление объектов, которые и так помечены как объекты на удаление? Звучит вроде здраво, @Max Kostikov что скажете?

Sat, 08 Aug 2020 12:07:17 +0300

Max Kostikov

kostikov@tiksi.net

@Blue

@ivan zlax удаление объектов, которые и так помечены как объекты на удаление? Звучит вроде здраво, @Max Kostikov Kostikov что скажете?

Я уже сказал. Не мешайте системе работать.

Майк как-то посоветовал...

Сомневаюсь что он это посоветовал, забыв, например, про содержимое таблицы iconfig.

Sat, 08 Aug 2020 12:13:45 +0300

Max Kostikov

kostikov@tiksi.net

Вообще говоря, крайне странная идея очищать свой собственный контент. Если он вам настолько не важен, то, возможно, не стоило его создавать вовсе?
С чужим, импортированным, это понятно.

Sat, 08 Aug 2020 12:22:04 +0300

Blue

blue@social.macaw.me

@Max Kostikov Да нет же, проблема не в этом, моя база раз в 5 больше чем у Ивана, с учетом того, что его сервер здесь намного дольше и, скорее всего социальный граф у него шире, так как у него больше пользователей - мне кажется что моя таблица слишком крупная. Прошли примерно сутки, размер таблиц пока не уменьшился, я переживаю что что-то идет не так. И я очень сомневаюсь что моего контента там наберется хотябы на тысячную долю от этого размера, так как я здесь в основном читаю, активный пользователь только я и еще один парень из Америки, у которого всего парочка постов. Но, опять же, если Вы скажете что это в порядке вещей, я скорее всего Вам поеверю

Sat, 08 Aug 2020 12:29:57 +0300

Max Kostikov

kostikov@tiksi.net

@Blue

Прошли примерно сутки, размер таблиц пока не уменьшился, я переживаю что что-то идет не так.

Занимаемое ею место само не уменьшится, если это InnoDB на MySQL. Если очень хочется то можно, действительно, OPTIMIZE TABLE items;, только, опять же, смысла в этом не много. Более того, разработчики MySQL писали что это, скорее, ухудшает общую производительность системы.

Sat, 08 Aug 2020 12:32:03 +0300

Max Kostikov

kostikov@tiksi.net

@Blue

я очень сомневаюсь что моего контента там наберется хотябы на тысячную долю от этого размера

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

Sat, 08 Aug 2020 13:15:02 +0300 last edited: Sat, 08 Aug 2020 13:16:14 +0300

ivan zlax

zlax@ussr.win

@Blue

Если очень хочется то можно, действительно, OPTIMIZE TABLE items;, только, опять же, смысла в этом не много.

Item. Обращу внимание, что у меня некоторые другие таблицы после оптимизации уменьшились с 1500мб до 200мб. Можно оптимизировать всю базу данных, все таблицы - одной командой:
mysqlcheck -o hubzilladatabasename
(после бекапа)

Sat, 08 Aug 2020 14:05:15 +0300

Blue

blue@social.macaw.me

@ivan zlax это, кажется, поздно делать - пишет что не смогла уместить куда то временный файл(

Sat, 08 Aug 2020 14:30:17 +0300 last edited: Sat, 08 Aug 2020 14:31:09 +0300

ivan zlax

zlax@ussr.win

@Blue я для этого останавливал mysql, копировал /var/lib/mysql по sftp на виртуальную машину с достаточным количеством ресурсов, там ставил ту же версию сервера баз данных после этого, он подхватил базу, проделал необходимые операции - и скопировал получившееся обратно.
С настройкам поумолчанию 7ГБ innodb файл около часа оптимизировался в mariadb 10.5, хотя контейнеру было выделено 16ГБ памяти и 8 ядер. С измененной конфигурацией 5гб файл оптимизировался уже за пару минут.

Sat, 08 Aug 2020 14:44:12 +0300

Blue

blue@social.macaw.me

@Max Kostikov А расскажите дилетанту, что в принципе делает эта операция и почему в ней мало смысла?

Sat, 08 Aug 2020 15:14:12 +0300

Max Kostikov

kostikov@tiksi.net

@Blue

А расскажите дилетанту, что в принципе делает эта операция и почему в ней мало смысла?

Освобождает неиспользуемые блоки, перестраивает индексы плюс всё сопутствующее. Почему мало смысла с точки зрения производительности пересказать не берусь. Почитайте в блоге разработчиков MySQL (или Percona, я уже точно не припомню).

Sat, 08 Aug 2020 15:20:02 +0300

Max Kostikov

kostikov@tiksi.net

Кстати, ещё советую отключить, или сильно ограничить по времени хранения и / или размеру, binary log в MySQL. Он, если у вас нет репликации, за исключением случаев каких-то серьёзных проблем с целостностью, нафиг не нужен, а места может занимать изрядно.

Sat, 08 Aug 2020 16:32:16 +0300

Blue

blue@social.macaw.me

@Max Kostikov У меня инноДБ, она, как и говорил Иван, пытается пересобрать а не оптимизировать таблицу. Таблица размером 23 гигабайта. Я нашел способ расширить /tmp Для нее до 25 гигабайт, но не выходит все равно - встал журналом и обнаружил что кто-то убивает (вот прямо kill -9) сервис марии...

Sat, 08 Aug 2020 16:39:00 +0300

Max Kostikov

kostikov@tiksi.net

@Blue

У меня инноДБ, она, как и говорил Иван, пытается пересобрать а не оптимизировать таблицу.

Да, оно так и работает с InnoDB.

Sat, 08 Aug 2020 16:51:48 +0300

Blue

blue@social.macaw.me

@Max Kostikov в сервис-файле есть вот такие строки... Видимо это не до конца работает)

KillSignal=SIGTERM

# Don't want to see an automated SIGKILL ever
SendSIGKILL=no

Sat, 08 Aug 2020 16:57:21 +0300 last edited: Sat, 08 Aug 2020 16:57:45 +0300

Max Kostikov

kostikov@tiksi.net

@Blue Говоря мягко, управление памятью далеко не самая сильная сторона Linux, так что ничего удивительного.
Если у вас проблема с дисковым пространством, можете попробовать сделать дамп таблицы с архивацией налету, удалить саму из базы и восстановить из архива, опять же, распаковкой налету. Может места и хватит.
По факту это будeт тот же TABLE OPTIMIZE.

Sat, 08 Aug 2020 16:58:32 +0300

ivan zlax

zlax@ussr.win

@Blue

Таблица размером 23 гигабайта. Я нашел способ расширить /tmp Для нее до 25 гигабайт, но не выходит все равно - встал журналом и обнаружил что кто-то убивает (вот прямо kill -9) сервис марии...

Ещё могу порекомендовать попробовать оптимизировать эти таблицы, перед item:
dreport, iconfig, term, xchan, photo

OPTIMIZE TABLE dreport;
etc

Возможно, их оптимизация освободит пространство необходимое для обработки item (лучше сразу сделать бекап базы, чтобы потом по нему сранвивать разницу)

Sat, 08 Aug 2020 17:06:31 +0300

Blue

blue@social.macaw.me

@Max Kostikov Да, кажется что вышибает по оом... А как это все провернуть?

Sat, 08 Aug 2020 20:02:52 +0300

Дима Ржевский

dmitry77@hubzilla.ru

Вообще тема актуальная. У меня тоже сервер забит и таблица "всего" 25 гб.
Стало тормозить - добавил оперативки но как я понимаю это не самое лучшее решение.

Sat, 08 Aug 2020 20:04:34 +0300

Дима Ржевский

dmitry77@hubzilla.ru

хорошобы удалять "мёртвых" пользователей совсем вместе с не востреборваным контентом.
@Max Kostikov а есть ли где описание БД?

Sat, 08 Aug 2020 20:50:17 +0300

Max Kostikov

kostikov@tiksi.net

@Дима Ржевский

а есть ли где описание БД?

Что-то есть в документации.
По удалению пользователей, я лично считаю это неэтичным. Но вам ничто не мешает делать это в ручном режиме или как-то автоматизировав этот процесс.

Sun, 09 Aug 2020 07:32:36 +0300

Дима Ржевский

dmitry77@hubzilla.ru

@Max Kostikov по поводу не этичности:
1)на главной странице я предупрежил что аккаунты будут удаляться
2)если к примеру акаунт не используется к примеру 3 года - скорее всего пользователю он не нужен. Можно удалять только то что другие не вели активности по нему ( не смотрел, не лайкали и проч)
Иначе hubzilla будет напоминать блокчейн - всё записывается и ничего е удаляется

Sun, 09 Aug 2020 07:47:37 +0300

Дима Ржевский

dmitry77@hubzilla.ru

@Max Kostikov

Что-то есть в документации.

да БД есть в документации (почему то в разделе Administrators а не Developers как я ожидал)

У меня вопрос: в некоторых самых больших каналах автор null .  Что бы это могло значить?

Смотрю так:
select  author_xchan , count(*), xchan_hash
      from item left join xchan on xchan_hash= author_xchan
      group by author_xchan having count(*) >10000
      order by count(*);

Sun, 09 Aug 2020 10:48:56 +0300

Lone wolf

neoferosium@hub.bessonnica.org

@Max Kostikov

Что-то есть в документации.
По удалению пользователей, я лично считаю это неэтичным. Но вам ничто не мешает делать это в ручном режиме или как-то автоматизировав этот процесс.

Но очень многие админы считают нормой. Мой видеоканал так погиб. Потом долго извинялись, обещали больше места, но мне уже не хотелось связываться с сервисом

Sun, 09 Aug 2020 11:51:10 +0300

Max Kostikov

kostikov@tiksi.net

@Дима Ржевский

У меня вопрос: в некоторых самых больших каналах автор null . Что бы это могло значить?

Не знаю что вы видите у себя, но у меня ни одного пустого author_xchan нет.

Sun, 09 Aug 2020 17:23:29 +0300

haver

haver@tiksi.net

@Max Kostikov

В /admin/site есть настройки хранения импортированного контента.
Можете также вынести из базы на диск хранимые там фото (кроме профилей) используя util/storageconv.

А изображения по дефолту хранятся как blob в БД?
util/storageconv только вытащит изображения из базы в файловую систему или поменяет систему хранения и изображения в дальнейшем будут хранится в файлах? Или настройки хранения можно поменять в админке?

Sun, 09 Aug 2020 17:32:03 +0300 last edited: Sun, 09 Aug 2020 21:01:00 +0300

Max Kostikov

kostikov@tiksi.net

@haver

А изображения по дефолту хранятся как blob в БД?

Смотря какие. Импортированные фото профилей всегда хранятся в базе данных, кэшируемые изображения никогда там не хранятся. Для прочих, основное загруженное фото всегда хранится на диске, а их миниатюры (создаётся 3 в дополнение к основному файлу) в зависимости от настройки места хранения - база данных или файловая система.

Или настройки хранения можно поменять в админке?

Это делается при помощи переменной конфигурации system.filesystem_storage_thumbnails.

Sun, 09 Aug 2020 20:50:59 +0300

Дима Ржевский

dmitry77@hubzilla.ru

@Max Kostikov извиняюсь ? item.author_xchan у меня всё тоже не null.
author_xchan не связан с xchan_hash

select  author_xchan , count(*), xchan_hash
      from item left join xchan on xchan_hash= author_xchan
      group by author_xchan having count(*) >10000
      order by count(*);

+----------------------------------------------------------------------------------------+----------+------------------+---------------+
| author_xchan | count(*) | xchan_hash | xchan_url |
+----------------------------------------------------------------------------------------+---------=-+----------------+---------------+
| 1VI57MB0EPQcN_QUdgcT5NpiM9xfOk-c-CgOSaY3wTeig8ohH.. | 142048 | NULL | NULL |
+----------------------------------------------------------------------------------------+------------+-----------------+-------------+

Sun, 09 Aug 2020 20:56:54 +0300

Max Kostikov

kostikov@tiksi.net

@Дима Ржевский Я чувствую вы что-то пытаетесь спросить, но у вас никак не получается. Какой, в конце-концов, вопрос то?

Sun, 09 Aug 2020 21:00:38 +0300

Дима Ржевский

dmitry77@hubzilla.ru

кто заспамил мой хаб? я не могу найти! 142048 постов!

Sun, 09 Aug 2020 21:07:07 +0300

Max Kostikov

kostikov@tiksi.net

@Дима Ржевский

кто заспамил мой хаб? я не могу найти! 142048 постов!

Это же ваш хаб. Откуда нам знать?
У меня на @Zotum, например, нет пустых полей xchan_hash в таблице xchan.

Sun, 09 Aug 2020 22:07:46 +0300

Дима Ржевский

dmitry77@hubzilla.ru

@Max Kostikov хаб то мой но программу писал не я. как база устроена я не в курсе

Sun, 09 Aug 2020 23:40:49 +0300

Max Kostikov

kostikov@tiksi.net

@Дима Ржевский Ну если у вас в базе явно что-то не так, то надо разбираться что именно. Смотреть ошибки, соответствие структуры базы, целостность и т.п.