Ну как дела с решением? очень много места занимают фоточки, которые принадлежали уже удаленным элементам
15.07.2016 12:08:58
Ну как дела с решением? очень много места занимают фоточки, которые принадлежали уже удаленным элементам
|
|
|
|
17.07.2016 16:02:55
Эдуард Пащенко, вот
Еще вот есть на гитехабе файлик |
|
|
|
24.09.2016 16:50:29
Вячеслав Шевченко, Спасибо за ссылки!
А как этот скрипт (с гитхаба) запустить в консоли, куда файл положить? |
|
|
|
23.11.2016 01:50:46
Чтобы узнать полный путь к корню, требуется перейти в папку с сайтом и набрать команду pwd, вы получите путь от корня к папке сайта. |
|||
|
|
27.11.2016 10:41:58
Василий, у меня скрипт не работает (или не подает признаки).
Делаю так:
|
|
|
|
28.11.2016 02:25:49
segolevd, в папке /var/www/uХХХХХ/data/www/site находится папка bitrix?
|
|
|
|
29.11.2016 13:44:18
Василий, да, именно там и находится
|
|
|
|
26.04.2017 16:47:00
Сибирский, не в PHP строке, а в консоли - CLI SAPI PHP
Голосуй за идеи по развитию API Bitrix:
|
|
|
|
15.06.2017 18:36:49
Андрей Николаев, для непонимающих...(это я), что такое CLI SAPI PHP. Куда положить скрипт и Как запустить этот скрипт.
|
|
|
|
16.06.2017 14:43:42
CLI PHP доступен через SSH. Размещаете скрипт на сервере/хостинге, через SSH-терминал переходите в папку где расположили скрипт и запускаете:
php имя_скрипта параметры |
|
|
|
21.07.2017 19:36:47
но скриптик можно чуть причесать, чтобы вывод был адекватней, или добавить элементы упрваления. у меня он нашел 2 файла ненужных. хотя там скрипт 2 строчки, читает из таблицы именя файлов, и сравнивает список физических файлов со считанными. |
|||
|
|
20.12.2017 23:08:01
Доброго времени суток, Друзья!
Хорошо, лежит мой файл clear_upload.php в корне сайта сайт работает на Вэб-окружении в VDS запускаю файл через терминал по SSH php clear_upload.php /home/bitrix/bagatelle.market получаю результат Cannot load Zend OPcache - it was already loaded Could not open input file: clear_upload.php Обращаюсь в поддержку к своему VDSнику... ответ Используйте полный путь к файлу clear_upload.php: php /home/bitrix/bagatelle.market/clear_upload.php Использую рекомендации VDSника запускаю php /home/bitrix/bagatelle.market/clear_upload.php получаю Cannot load Zend OPcache - it was already loaded Usage: php clear_upload.php [--delete-files] /path/to/document/root Скрипт для очистки каталога upload/iblock от неиспользуемых файлов (оставшихся после удаления элемента инфоблока). Проверяет каждый файл в каталоге upload/iblock, есть ли он в таблице b_file и если его там нет выводит полный путь к нему на экран, а если указана опция --delete-files, то удаляет файл. В режиме удаления (с опцией --delete-files), если каталог, в котором находился удаляемый файл становится пустым - удаляет и его. Примеры использования: Получить список всех неиспользуемых файлов из каталога upload/iblock: php clear_upload.php /var/www/example.com Удалить все неиспользуемые файлы из каталога upload/iblock: php clear_upload.php --delete-files /var/www/example.com Я конечно немного Гусь во всем этом, но разобраться так и не могу Может кто что процитирует? За что огромное спасибо! |
|
|
|
29.12.2017 18:21:03
Судя по дате создания темы и дате последнего поста, тема жива.
Вопрос простой: а силами программистов Битрикс этот вопрос решить нельзя? Модуль какой-нибудь или Человеко_Понятную инструкцию? На пальцах... ... а не для тех кто сам может PHP-скрипт написать! Спасибо. |
|
|
|
29.12.2017 20:25:34
Силами програмистов битрикса вопрос решен заочно, в upload не создаеться лишних файлов/мусора, кроме может быть папки "tmp" и "resize_cache".
Все что создано в upload битриксом завязано на админку и удаляеться связанными обьектами(инфоблоки, галереи, юзеры, заказы, тд). Напрямую из папки Вам удалять нечего не нужно. То есть например у вас кончилось место на хостинге, так как Ваш фотограф залил фотки по 20 метров, тогда Вы в админке можете найти эти фотки, удалить и залить вместо них фотки поменьше. Не трогая папку upload. Все "лишнии файлы" созданы доработками или вручную. Их автоматика не почистит, так как нету четкого критерия для определения подобных файлов. Если лишние файлы созданы доработками, то обращайтесь к ТП разработчика этих доработок. Если лишнии файлы созданы вручную, то это ваша отвественность за ними следить и чистить в случае необходимости. Я бы только для разрабов битрикса предложил бы добавить средства аналитики и отчеты для хранилища. Плюс тесты для проверки наличия файлов и потерянных/незадействованных записей из за кривого кода сторонних разрабов. |
|
|
|
29.12.2017 20:52:03
недавно сам это проверял - resize_cache аналогично все грохает и обновляет когда надо т.е. если менялись или удалялись там обновит и удалит предыдущее это конечно если пользоватся провереным временем старым api инфоблоков |
|||
|
|
29.12.2017 21:39:17
Да, грохает если удалять через апи, но вот если поменялись параметры генерации миниатюр, или водянка другая, то старье не чиститься, так как оригинал на месте. Но в таком случае это уже этап разработки/внедрение и делаеться разрабом, а не юзером. Плюс стороние модули могут что то этакое генерить, что не почиститься автоматом..
|
|
|
|
29.12.2017 23:33:54
Да, ну а теперь не очень гипотетический момент: Есть сайт, которому Пять лет, он прекрасно работает... на Ubuntu 9 и Php 5.3.3
Чтобы всё не проИкать, хочется сделать бэкап и попробовать всё это на виртуалке (уже знаю, что на Centos 7 не будет работать) Предыдущий админ с запасом выбрал хостинг. Всё нормально. было... 5 лет назад. Наверное, даже два года назад. Теперь, когда хозяин говорит: Ну нормально же вчера работало, - твои попытки объяснить, что не хватает гигов пять для бэкапа - не очень убедительны! Теперь.. .. я вижу 3 Гига не знаю чего . И как мне определить насколько это важное или не особо важное ГЭ? И, опять же - вопрос - Что делать? |
|
|
|
30.12.2017 19:59:01
Типового веб/битрикс инструмента для визуализации занимаемого места пока не втречал. Разве что файловый менеджер в панели хостинга.
Утечка свободного места может быть по самым разным причинам. Во-первых посмотрите занимаемое место на диске для самих файлов. Бывает что файлы занимают мало, а база много. Обычно это гиганский журнал или мусор, который по какой то причине не зачистился агентами. Если это ваш случай, то смотрите какая именно таблица растет и гуглите ей название. Как правило это типовые ошибки которые уже давно все решили. Подход к отладке занимаемого места довольно элементарный. Берете файловый менеджер или консоль/терминал (что Вам удобней) и смотрете какие именно файлы и папки сколько занимают. Например, нашли кучу пдфников, которые у вас на сайте не где не используються, дальше выясняете кто и зачем туда их залил и нужны ли они там. Как я за вас это определю? Бывает что стороние модули или просто скрипты дороботок генерят логи и не умеют их чистить. Запросто может быть один тесктовый файл логов на пять гигов. Возможно делали вручную экспорт и не почистили. Если утечка в "/upload/medialibrary/" или "/upload/iblock/" или "/upload/uf/", то чистите через админку, в соотвествующих разделах. Напрямую эти файлы трогать нельзя. "/upload/resize_cache" и "/upload/tmp" в резервную копию не идут. Но если утечка в "/upload/resize_cache/", то это шаблоны компонентов надо проверять/оптимизировать. Впринципе можно напрямую удалить содержимое "/upload/resize_cache/" и сбросить кеш в админке. Но это временное решение, на час, на день, на месяц, а может на год. Зависет от вашего проекта. |
|
|
|
28.01.2018 13:20:39
проверить что именно? если функционал сайта - то при создании резервной копии папку upload исключить и все. все 10 гигабайт картинок там не нужны совсем и не зачем их тащить на тестовую площадку. |
|||
|
|
13.04.2018 22:45:19
Добрый вечер. Подскажите. У меня в папке upload есть подкаталоги 0_files /upload/1_files Также есть каталог в корне сайта C:\xampp\htdocs\it\0_files По поводу 1го и 2го каталога я знаю точно, что туда его не переписывал и не заливал. Откуда они взялись я не знаю. Внутри каталогов подкаталог iblock см рис, в котором частично дублируются файлы каталога инфоблоков /upload/iblock Предполагаю, что при какой-то операции движок или какая-либо программа создали копию каталога инфоблока.
А вопрос такой, откуда эти каталоги могли взяться и можно ли их удалить? Никто не сталкивался? |
|
|
|
14.04.2018 11:25:26
|
|||
|
|
12.05.2018 18:25:42
Ребят такая же проблема . Я ее решил следующим образом. Разместил скрипт clear_upload.php в корне сайта. Хостинг у меня бегет. В ssh перехол в корневую директорию и выполнил команду php clear_upload.php --delete-files /var/www/example.com По сути как и указанно было в мануале в итоге 13900 картинок удалилось то есть Гиг освободил сайт работает все гуд.
Всем спасибо |
|
|
|
14.06.2018 17:57:05
|
||||
|
|
|||