2000 $ В месяц ( пятидневка , по 8 часов) или же 25$ / час.
Я вам не смогу сейчас точно пояснить как происходит работа с памятью, но из личного опыта замечено что на Linux тачках это вполне закономерно.... т.е если у вас ~2 GB и есть LAMP то будет написано что занято все...... Хотя при этом будет все по прежнему нормально работать.
Вы так бюджет и не огласили :)
VIRT — общее количество виртуальной памяти, используемой программой. Значение в килобайтах.
Настоятельно рекомендую ознакомиться : http://kryukov.biz/wiki/Top
Romka_Kharkov добавил 30.04.2010 в 23:59
CentOs 5.4
8 ядер, 10 гиг памяти
top - 15:58:34 up 42 days, 13:11, 1 user, load average: 3.42, 3.38, 3.45 Tasks: 272 total, 3 running, 268 sleeping, 0 stopped, 1 zombie Cpu0 : 16.5%us, 18.5%sy, 0.1%ni, 57.7%id, 6.4%wa, 0.1%hi, 0.7%si, 0.0%st Cpu1 : 4.3%us, 7.1%sy, 0.1%ni, 87.7%id, 0.8%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 8.1%us, 15.8%sy, 0.0%ni, 74.9%id, 1.2%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 6.5%us, 12.8%sy, 0.1%ni, 79.8%id, 0.9%wa, 0.0%hi, 0.0%si, 0.0%st Cpu4 : 4.0%us, 6.2%sy, 0.1%ni, 88.8%id, 0.9%wa, 0.0%hi, 0.0%si, 0.0%st Cpu5 : 4.0%us, 6.3%sy, 0.1%ni, 88.6%id, 0.9%wa, 0.0%hi, 0.0%si, 0.0%st Cpu6 : 7.5%us, 14.1%sy, 0.1%ni, 77.2%id, 1.1%wa, 0.0%hi, 0.0%si, 0.0%st Cpu7 : 8.0%us, 14.8%sy, 0.1%ni, 75.8%id, 1.3%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 10237780k total, 9557776k used, 680004k free, 2524636k buffers Swap: 4192944k total, 200k used, 4192744k free, 4192852k cached
Я думаю вас посадить должны как минимум за это ;)
Все соберут свои узелки... И поедут ;)
С Удовольствием бы поделился своим методом с вами, но боюсь это будет немного не честно, у меня более 6 лет опыта работы на должностях из серии "Unix Системный Администратор"/"Менеджер отдела Системных Админов".
По этому мой метод проверки разведет еще больший оффтоп в теме, разговор действительно отошел от основного русла, мочите хостера!!!!!! :D :D :D
"Определить проблему" может только инженер узла о котором мы говорим, клиент может только предполагать и делать какие-то собственные заключения из анализа происходящего.....
Я кстати уже предложил более интересный и "правильный" вариант проверки "работоспособности сайта", меня лично не интересует что там случилось, кабель порезали или винт сгорел или или или, меня интересует доступность моего ресурса.
Концепция проверки: конектимся на 80 , делаем GET запрос своего сайта, данные (код ответа сервера, время ответа) анализируем , выполняем результат в зависимости от анализа...
На сегодня я знаю как минимум 10 средств из серии (cacti, nagios, zabbix), последний даже есть в виде бинарей для win32, которые имеют шаблоны мониторинга FTP / HTTP / и других сервисов... Ну я вообще молчу что можно написать php / perl скриптик в 10 строк который будет делать тоже самое и повесить его в cron :))
В результате проверки мы получаем ответ в любом виде, хоть в процентах в месяц, сколько был недоступен веб сервер..... когда... какие периоды, можно даже графики строить.... если вы говорите о наблюдениях в течении более часа... полагаться на ICMP вообще нет смысла, процент потерь между "миром" выхватите в любом случае ...... Но главное , что мы будем точно знать, что мы мониторили тем же методом (запросом) как и браузер в случае клиента который посещает ваш сайт, а вы опираетесь на не совсем относящиеся к конкретному сайту tracert и ping ... в результате на срезе в 1 сутки например понимаем, что мы не пингали 50% времени сайт, потому что сработала система какая-то и залочила ICMP... потому что регулярность под ее фильтры попала....... Но это же не означает что перестал работать сайт :))))
Romka_Kharkov добавил 29.04.2010 в 23:51
ТС,
А что такое?
Я не утверждаю, что проверяемый хост 200% стабилен, вы не подумайте, я лишь как технический специалист поправил вас в том, что анализ доступности хостера путем PING это все равно что кидать камешки в реку и ждать пока она из берегов выйдет :)))) Результат не может быть достоверным по ряду причин, во первых доставку echo запросов и ответов ни кто не гарантирует, во вторых не исключено что на маршруте в 11 хопов кто-то не режет ICMP просто потому-что....
Программа которая щупает сквозь файрволы :))) ? Любопытно аж до не могу :)) Как же этой ей удается? :) Поделитесь технологией ?:)
Что же касается "tracert" / "traceroute", так вот собственно http://ru.wikipedia.org/wiki/Traceroute
Так что от ICMP мы далеко не уехали , если я пожелаю вы не увидите ни одного хоста в трейсроуте внутри моей сети, а так же сам мой пограничный маршрутизатор, в tracert У вас будут звездочки, но это не коем образом не мешает мне отдавать с того же сервера (подсети) сайты в полном объеме. Мало того, в моем ведении еще получается вариант ответа который вы увидите :))) Может быть timeout может быть unreachable, А может быть и prohibited...
Так что не советую вам в будущем штурмовать провайдера услуг опираясь на ICMP ping .... ;) Я понимаю вы бы посмотрели таблицу маршрутизации BGP мировую и зафиксировали изменения маршрутов для этой автономной системы, в таком случае можно было бы утверждать что меняя маршруты хостер меняет физику включения, а именно какие-то проблемы с основным каналом или с одним из каналов...
P.S: Если я не ошибаюсь то основная задача указанного вами софта это поиск игровых серверов, а функции ping / tracert там для удобства клиента... Это сути описанного не меняет, но выглядит странновато ;)
Добавлено:
Изучив более детально ваш скриншот я заметил , что изменение маршрута таки фиксируется, черным блоком на графике, но видимо новый маршрут не отображается, до чего же я люблю "mtr" показывается даже направление асимметричного трафика, а тут как-то не понятно, например могу предположить, что программа не стала показывать "Другой маршрут".... после того как пропал линк с первым.... не ясно что вложили её разработчики (или может быть даже переводчики) в смысл "Другой маршрут"...
Если вас интересует работа сайтов с конкретного ИП я бы рекомендовал мониторить на прикладном уровне OSI, т.е сделать мониторинг 80 го порта к примеру... потому, что исходя из логики в случае с хостингом клиенту все равно, через какой канал и как он запущен (я не говорю про клиентов чей трафик зависит от паритетных каналов городских или регональных), клиента интересует что бы его сайт отображался... по этому говоря техническим языком нам надо что бы на 80м порту указанного ИП отвечал наш сайт при условиях его запроса, вот и скажите мне, зачем при этом мониторить возможность прохождения ICMP пакетов сквозь всю цепочку, если нас предельно точно интересует 80/TCP ?!
Поясняю, совсем не обязательно IP адрес на котором расположен сайт должен пинговаться, так же пограничные маршрутизаторы провайдеров в большинстве случаев не отвечают на ICMP запросы, а в редких случаях могут быть настроены на определенное кол-во таких запросов от одного адресата, таким образом чем дольше вы долбите ... тем хуже вам видно ;) Но это касается ICMP протокола.
В общем к чему это я , показатель пингов.... это в общем-то не показатель .... В совокупности с другими данными... да... может быть.... но вы приводите только маршрут который на "последнем хопе" показывает потери ICMP запросов, а что у вас в этот момент с TCP происходит в ту же сторону? Где показатели? Да с ICMP явно проблемы, но к работе сайтов это в принципе отношения не имеет. Могу для вас модулировать такую ситуацию, что бы вы убедились... на графике будет точно такая-же "красная лента"... а сайт вы будете открывать с максимальной скоростью канала доступного между нами....
Сопутствующие доки:
http://ru.wikipedia.org/wiki/ICMP
