Форум русскоязычного сообщества Ubuntu


Увидели сообщение с непонятной ссылкой, спам, непристойность или оскорбление?
Воспользуйтесь ссылкой «Сообщить модератору» рядом с сообщением!

Автор Тема: Как защитится от зависания системы при открытии большого файла в браузере  (Прочитано 1112 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн Zenit

  • Автор темы
  • Любитель
  • *
  • Сообщений: 56
    • Просмотр профиля
Добрый день. Сразу извиняюсь, если дубль какой либо темы. Поиском пользовался - не нашел ничего подобного.
Сразу напишу система Kubuntu 16.04, браузер Chrome.

Ситуация такова, по работе приходится иногда открывать в браузере xml-файлы(сайтмапы изображений или просто сайтмапы сайтов), иногда их выполняют не совсем грамотно запихивая в эти сайтмапы очень большое кол-во записей. Это понятное дело не совсем правильно и в этом случае я со своей стороны заставляю программистов переделывать эти файлы.
Но в случае если возникает такая ошибка моя Kubunta 16.04  зависает наглухо.

Или вот еще случай - открывал html файл с простейшей разметкой с помощью таблицы в которой было 98500 строк - файл открылся, я выполни ctrl+a, затем ctrl+c, затем в гугл-доксе попытался выполнить ctrl+v - система так же зависла наглухо. Я думал, может через буфер - пока "прокачается" эта информация - но компьютер висел в течении полутора часов - после чего я его просто ресетнул.

Вопрос собственно в чем - возможно ли как-то защитится от подобного рода уязвимости, по меньшей мере, что б не зависала вся система целиком. Потому, что реагировать отказывается как КДЕ, так и элементарно не переходит на консоль путем нажатия ctrl+alt+F1(-F6).
Не знаю как это правильно называется - переполнение буфера или как-то по другому.

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


ТС не появлялся на Форуме более трех месяцев по состоянию на 05/12/2019 (последняя явка: 31/08/2019). Модератором раздела принято решение закрыть тему.
--zg_nico
« Последнее редактирование: 05 Декабрь 2019, 08:22:23 от zg_nico »

Оффлайн snowin

  • Активист
  • *
  • Сообщений: 844
    • Просмотр профиля
Zenit, дык, очевидно, что не хватает оперативки и места на свопе
при необходимости, если своп на разделе можно создать файл диске, вместо
можно также резать тот же xml на кусочки

Оффлайн Zenit

  • Автор темы
  • Любитель
  • *
  • Сообщений: 56
    • Просмотр профиля
Оперативки 8 Гб, без свопа. Свап добавил 16 Гб. Возможна ли причина в этом(то, что отсутствовал своп)?

Оффлайн snowin

  • Активист
  • *
  • Сообщений: 844
    • Просмотр профиля
Возможна ли причина в этом(то, что отсутствовал своп)?
это очевидно
а размер xml?

Оффлайн EvangelionDeath

  • Администратор
  • Старожил
  • *
  • Сообщений: 3276
  • Ubuntu Mate 16.04 х64
    • Просмотр профиля
Zenit, Возможно. Но слишком большым его тоже делать не стоит
1) Поставьте SWAP 2-4GB
2) поэксперементируйте с vm.swappiness
Fujitsu UH552: Intel Core i3-3217U, 16GB DDR3 1600MHz, Intel HD4000, Intel 535 120GB/Ubuntu 16.04 Mate
HP 625: AMD Athlon P320, 4GB DDR3 1333MHz, AMD HD4250, Seagate Momentus/Ubuntu 14.04 Mate

Оффлайн Zenit

  • Автор темы
  • Любитель
  • *
  • Сообщений: 56
    • Просмотр профиля
Спасибо. за ответы. Свап поставил 16гб(2 обьема оперативки), теперь думаю об уменьшении его. Понаблюдаю теперь за системой.
рамзер XML при котором завис был примерно 34 мб

Оффлайн snowin

  • Активист
  • *
  • Сообщений: 844
    • Просмотр профиля
рамзер XML при котором завис был примерно 34 мб
вообще ни о чем, - не должен был зависнуть
может проблема в структуре?

Оффлайн Zenit

  • Автор темы
  • Любитель
  • *
  • Сообщений: 56
    • Просмотр профиля
Ну и я думал, что ни о чем. 34 мб - это ж смешно. А как выше привел пример HTML страничка с табличной разметкой в 98500 строк - загрузилась, скопировалась, но вставляться в гугл-докс не захотело и повесило всю систему. Возможно это дело в браузере(Chrome)?
Но я вопрос потому и задал, что возможно как-то можно изолировать проблему браузера от системы, что бы не зависала вся система. Справедливости ради, я провел тест с той же табличкой на 98500 строк и гугл доксом еще на двух компьютерах в офисе на винде и на iMac(Система Yasemit) - в обеих случаях браузер долго думал, потом вывалил алерт, что страница гугл-докса не отвечает и предложил закрыть вкладку. Но не блокировалась сама система ни в случае с виндой, не в случае с маком.
В случае же если я копировал эти 98500 строк и вставлял в табличку LibreOffice - все отрабатывалось корректно(это я только что протестил).

Оффлайн snowin

  • Активист
  • *
  • Сообщений: 844
    • Просмотр профиля
В случае же если я копировал эти 98500 строк и вставлял в табличку LibreOffice - все отрабатывалось корректно(это я только что протестил)
и зачем сие?
попробуй эту html-страничку открыть непосредственно в офисе

Оффлайн Zenit

  • Автор темы
  • Любитель
  • *
  • Сообщений: 56
    • Просмотр профиля
Мне ее нужно в гугл-докс закинуть. Это по работе.
Есть проект - конкретно копирайтеры пишут рецензии на книги, мне проще один раз залить на гугл-докс, а у них уже есть ссылки, чем рассылать куче копирайтеров один и тот же файл.

Я в итоге импортировал в гугл-докс путем импорта файла(там есть такая функция).

Но по работе системы возник такой вот вопрос.

Оффлайн snowin

  • Активист
  • *
  • Сообщений: 844
    • Просмотр профиля
Но по работе системы возник такой вот вопрос.
проведи следственный эксперимент
скопируй эти данные из html в какой-нить текстовый файл и посмотри не будет ли зависать, и мониторь память, тем же top

Оффлайн Zenit

  • Автор темы
  • Любитель
  • *
  • Сообщений: 56
    • Просмотр профиля
ну такое, kate вообще сделал вид, что я в него ничего не пытался запихнуть)) А либрофис в режиме типа текстового редактор -тупил 30 минут и так и не загрузил. Я даже хотел видео записать с экрана, но по прошествии 30 минут плюнул на это дело. Так, что даже не знаю. Ясен пионер, что такие задачи скорее исключение, но вот такая фигня, загрузка ОЗУ выше 5 ГБ не поднималась, своп вообще по нулям

Оффлайн Morisson

  • СуперМодератор
  • Старожил
  • *
  • Сообщений: 4588
    • Просмотр профиля
Zenit, а нагрузка на проц? Открой системный монитор и проделай эту манипуляцию.

Оффлайн snowin

  • Активист
  • *
  • Сообщений: 844
    • Просмотр профиля

Оффлайн Zenit

  • Автор темы
  • Любитель
  • *
  • Сообщений: 56
    • Просмотр профиля
Нагрузка проца - htop показывал 100% по одному ядру, всего их 8. Приложение которое отъедало эти 100% ядра был либрофис.
Что касается комманды free я попробую ее завтра, сегодня уже уехал с работы.Результат приведу тут.

 

Страница сгенерирована за 0.562 секунд. Запросов: 22.