Комментарии 44
Ужасно чешутся руки проверить! Может, стоит перенести топик в закрытые?
А вы уверены что ограничения Java машины на процесс не выкинут вовремя исключение о том что память кончилась и никакого падение в своп не будет?
Мне кажется это логичной мерой. ведь в Java использование памяти жестко лимитируется.
Мне кажется это логичной мерой. ведь в Java использование памяти жестко лимитируется.
Я в другом у них уязвимость нашёл. Отправил, так же сказали учтут. Но публиковать пока не буду, уж больно она каверзная. По телефону горячей линии оператор вообще не поняла о чём речь. Но там дело обстоит игрой с датой отправки.
Хотя в этой организации, думаю пока жаренный петух не клюнет. Не дёрнутся.
Хотя в этой организации, думаю пока жаренный петух не клюнет. Не дёрнутся.
«А если неправильные настройки ОС, и она начнет свопится, то недалеко и до аппаратной смерти сервера.»
Расскажите пожалуйста каким образом свопящийся сервер может умереть аппаратно.
Расскажите пожалуйста каким образом свопящийся сервер может умереть аппаратно.
Аппаратный сбой HDD из-за большого кол-ва операций.
А почему, вы думали, падают кластеры/облака и почему их так долго поднимают?
Когда падает часть кластера, на остальные узлы попадает чрезмерная нагрузка, из-за которой отказывает аппаратура на новых узах. И так далее — цепная реакция. Пока не придет «лесник» ивсех разгонит остановит работу всего кластера, перенастроит и запустит в щтатном режиме.
А почему, вы думали, падают кластеры/облака и почему их так долго поднимают?
Когда падает часть кластера, на остальные узлы попадает чрезмерная нагрузка, из-за которой отказывает аппаратура на новых узах. И так далее — цепная реакция. Пока не придет «лесник» и
Вроде кластеры на то и нужны чтобы резерв давать при таких ситуациях. А сбой HDD в таких системах должен быть тем более предсказуемо резервируемым событием.
У любой системы есть предел устойчивости. И любую систему делают с неким запасом по прочности, но не более, чем это целесообразно. И кластеры тоже имеют предел. Когда есть 1 сервер под DDoS'ом, то он под такой дикой нагрузкой может проработать, допустим в среднем 3 дня, то когда есть 1000 серверов, каждый час вылетает (грубо) по 14 серверов. В кластере не делают сверх надежных узлов, потому что это 1) дорого 2) не нужно. Делают с определенным запасом, но не более того.
Я так и не понял, откуда вы выводите зависимость времени работы сервера от его нагрузки. Единственный вариант, который я знаю — это херовые БП, которые при нагрузке проседают по напряжению. Но это мир лоукостных десктопов, а не серверов.
В кластерах обычно используют то же железо, что и для обычных серверов, просто потому, что так проще. Типичные юнитовые/полуюнитовые платформы. В стоимости эксплуатации железо, конечно, играет некоторую роль, но не самую значительную, ибо плотность размещения и эксплуатационные расходы выше.
В кластерах обычно используют то же железо, что и для обычных серверов, просто потому, что так проще. Типичные юнитовые/полуюнитовые платформы. В стоимости эксплуатации железо, конечно, играет некоторую роль, но не самую значительную, ибо плотность размещения и эксплуатационные расходы выше.
свап не сможет физически убить сервер. Не знаю как в виндусе, а в линупсе либо он повиснет намертво, либо оом киллер убьет жабосервер.
А скажите пожалуйста, сколько свопящихся серверов на вашей практике, умерло аппаратно?
НЛО прилетело и опубликовало эту надпись здесь
«аппаратный сбой HDD из-за большого числа операций»? Извините, вы несёте чушь. throttling — да, лаги — да. Я ни разу не видел «аппаратных сбоев» из-за большого числа операций. Причина проста — если в диске забить очередь заданий, то он просто перестанет принимать новые, пока не выполнит старые. Таким образом, никаких «аппаратных сбоев» там быть не может — диск будет делать столько операций, сколько может (и весь мир подождёт).
Полтора часа прошло, а ржд не лежит, так что или все нормально работает, или что-то не так с хабром.
width у них, кажется, умножается на 194 у них. :)
Error 500: java.lang.OutOfMemoryError
ну сколько раз можно говорить, что обязательно проверять все входные данные на допустимость!
«учтут» они…
«учтут» они…
Ох, это далеко не единственный сайт…
standartno.ru/Captcha.ashx?w=8000&h=3200&c=GK/z8VK2MYE0uJ+kbVS53w==&bc=ffffff
Вруцентре такая же беда…
standartno.ru/Captcha.ashx?w=8000&h=3200&c=GK/z8VK2MYE0uJ+kbVS53w==&bc=ffffff
Вруцентре такая же беда…
Автор, закройте топик, или хабралюди полезут проверять!
Может быть, иначе и не закроют дыру. Как говорится, «пока гром не грянет, мужик не перекрестится» (ц). А ведь залатать дыру дело нескольких минут.
Увы. Дело нескольких минут — внести изменения в код. Вынести на боевой сервер — может занимать часы. С учетом тестов, согласований и прочего. Тут конечно бюрократия наносит страшный удар по пользователям.
Ха! Минут!? Нескольких дней! ))
Сначала человек, отвечающий за прием сообщений с сайта, сообщит об этом главному по ИТ.
Тот прочтет письмо только через день и перенаправит его главному по веб. Главный по веб выйдет из отпуска через несколько дней и назначит «ASAP-пипецсрочно-приступитьнемедленно» таск разработчику.
Тот офигеет от такого события, особенно не поняв с чего такой кипеш по поводу каких-то банальных проверок левых парамтеров. Но на следующий день пофиксит (скорее всего только в этом месте и только половину уязвимостей)
Дальше это все пойдет в отдел QA, который вообще не поймет в чем проблема, «картинка же показывается!»
Ну и потом все это пойдет по цепочке наверх, чтобы сформировать очередную итеррацию по выкладыванию фикса на продакшн.
Чтоб еще страшнее было — могу рассказать, как случайно выложат какие-то левые изменения относящиеся к еще не реализованной фиче, скрипт еще денек не будет работать и т.д. и т.п.
Хотя, может это я такой пессимист и у них там все будет хорошо )))
Сначала человек, отвечающий за прием сообщений с сайта, сообщит об этом главному по ИТ.
Тот прочтет письмо только через день и перенаправит его главному по веб. Главный по веб выйдет из отпуска через несколько дней и назначит «ASAP-пипецсрочно-приступитьнемедленно» таск разработчику.
Тот офигеет от такого события, особенно не поняв с чего такой кипеш по поводу каких-то банальных проверок левых парамтеров. Но на следующий день пофиксит (скорее всего только в этом месте и только половину уязвимостей)
Дальше это все пойдет в отдел QA, который вообще не поймет в чем проблема, «картинка же показывается!»
Ну и потом все это пойдет по цепочке наверх, чтобы сформировать очередную итеррацию по выкладыванию фикса на продакшн.
Чтоб еще страшнее было — могу рассказать, как случайно выложат какие-то левые изменения относящиеся к еще не реализованной фиче, скрипт еще денек не будет работать и т.д. и т.п.
Хотя, может это я такой пессимист и у них там все будет хорошо )))
Замечательную зебру можно сгенерировать размером в 20 700px × 5 000px. Больше по размеру не получается сделать, различные ошибки выдаёт.
Да это что… Вот на Zakupki.gov файлы можно заливать какие хошь zakupki.gov.ru/pgz/documentform?id=null&class=null&docType=null
Так вот почему им понадобилось 770млн. на модернизацию…
Хм. А если им залить туда что-то запрещенное, а потом пожаловаться что они это хранят у себя на серверах?
Пример файла, только что залитого на zakupki.gov.ru через эту «дыру»:
Адрес http://zakupki.gov.ru/pgz/documentdownload?documentId=39240775 как бы говорит нам, что можно скачать все документы, на zakupki.gov.ru залитые, перебирая их номера.
Адрес заливки, кстати, может быть проще: http://zakupki.gov.ru/pgz/documentform (несуществующие параметры самостоятельно принимают там значение «null»).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Когда просто отфильтровать параметры запроса недостаточно или о вреде универсальности