-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Неплохой хостинг на SSD - 20GB, 1Tb - всего за $5 - рабочий сервер через 55сек.
- Автор темы confguru
- Дата начала
keltanas
marty cats
Redjik
Без постоянной нагрузки эти цифры смысла не имеют, ИМХО. А хайлоада никакого у меня нет. Чисто замена шареду.
PS: Вместо мускуля у меня перкона с файликом my-medium.cnf
Без постоянной нагрузки эти цифры смысла не имеют, ИМХО. А хайлоада никакого у меня нет. Чисто замена шареду.
PHP:
# free
total used free shared buffers cached
Mem: 507576 353112 154464 0 54176 143840
-/+ buffers/cache: 155096 352480
Swap: 0 0 0
PHP:
# python ps_mem.py
Private + Shared = RAM used Program
96.0 KiB + 52.0 KiB = 148.0 KiB acpid
148.0 KiB + 28.0 KiB = 176.0 KiB atd
160.0 KiB + 21.5 KiB = 181.5 KiB mdadm
184.0 KiB + 22.0 KiB = 206.0 KiB mysqld_safe
168.0 KiB + 86.0 KiB = 254.0 KiB upstart-socket-bridge
216.0 KiB + 72.5 KiB = 288.5 KiB cron
256.0 KiB + 108.5 KiB = 364.5 KiB upstart-udev-bridge
324.0 KiB + 114.5 KiB = 438.5 KiB su
412.0 KiB + 28.5 KiB = 440.5 KiB dbus-daemon
504.0 KiB + 111.0 KiB = 615.0 KiB sudo
692.0 KiB + 153.0 KiB = 845.0 KiB ntpd
760.0 KiB + 147.5 KiB = 907.5 KiB init
708.0 KiB + 270.0 KiB = 978.0 KiB getty (6)
1.2 MiB + 70.0 KiB = 1.3 MiB rsyslogd
1.0 MiB + 290.5 KiB = 1.3 MiB udevd (3)
1.6 MiB + 108.5 KiB = 1.7 MiB sendmail-mta
1.2 MiB + 1.1 MiB = 2.3 MiB nginx (2)
964.0 KiB + 1.6 MiB = 2.5 MiB sshd (3)
3.1 MiB + 860.0 KiB = 3.9 MiB bash (2)
20.6 MiB + 39.8 MiB = 60.4 MiB php5-fpm (4)
85.6 MiB + 220.5 KiB = 85.8 MiB mysqld
---------------------------------
165.0 MiB
=================================
Во, супер!
Все поставилось
Сегодня Амстердам у них был забит по самое нехочу:
Amsterdam Capacity Issue
Fri Jun 21 13:37:00 2013
We have disabled droplet creation in Amsterdam. We are currently adding capacity in our Amsterdam Data Center and will be re-enabling creates as soon as possible.
There are no actions that need to be taken by customers.
Fri Jun 21 13:40:42 2013
Amsterdam Capacity Issue
Fri Jun 21 13:37:00 2013
We have disabled droplet creation in Amsterdam. We are currently adding capacity in our Amsterdam Data Center and will be re-enabling creates as soon as possible.
There are no actions that need to be taken by customers.
Fri Jun 21 13:40:42 2013
20 гб за 5$ при стоимости SSD за 1гб 0.8 - 1$ - экономически нецелесообразно (значит где-то подвох) + стомость железа, +стомость 1 ГБ Registred ECC оперативы, +оплата трафика, содержание инфраструктуры. Бесплатный сыр какой-то + ущербность SSD.
При стоимости железа и стоимости колокейшена в 100$ в месяц можно двух процессорный ксеннон замутить с 32-64 гигами Registred ECC на 5-ти SAS'ах в 5-м рейде, с IPMI и разместить его в дата центре каком-нибудь быстром и рядом (москва, спб), обойдется он как одна - две закрплаты ведушего программиста, но раз и на всегда. Плюс SAS в пятом рейде куда быстрее и надежней.
Скинте сюда результат утилиты dmidecode и hwinfo на этом vpn
Кстати, разве можно свопить SSD?
При стоимости железа и стоимости колокейшена в 100$ в месяц можно двух процессорный ксеннон замутить с 32-64 гигами Registred ECC на 5-ти SAS'ах в 5-м рейде, с IPMI и разместить его в дата центре каком-нибудь быстром и рядом (москва, спб), обойдется он как одна - две закрплаты ведушего программиста, но раз и на всегда. Плюс SAS в пятом рейде куда быстрее и надежней.
Скинте сюда результат утилиты dmidecode и hwinfo на этом vpn
Кстати, разве можно свопить SSD?
Да, быстрей. У меня дома рейд собран на четырех сатах, на P55 чипсете, так вот, работает этот рейд быстрее SSD (два тома в одном массиве, один 0-й, второй 5-тый). Пятый конечно немного уступает, но на чтение и стабильность гарантировано... Добавь суда SAS'ы c 15к скоростью (плюс сама шина).
Ext4 работает на порядок быстрее Ext3, плюс если сделать небольшой тюнинг, то write будет быстрее. XFS конечно быстрее, но я пока за стабильность. Плюс SSD имеет ограниченное количество циклов перезаписи, а магнытные носители - стабльней. Представте, что в каком-нибудь рейде (SSD тоже могут быть в рейде) одновременно откажет несколько носителей... Серверное железо - много записи - например, теже сессии... Имхо, что бы на сервере юзать SSD, то на него нужно снижать нагрузки на запись (те же сессии хранить в памяти), темпы, логи ложить в отдельный HDD, снижать запись на носитель. А если полетит суперблок? все - считай просрали всю инфу. SSD целесооразно использовать на рутовый раздел , где нет записи в 1-м рейде. На /var /home /tmp нужен обычный.
Про какие цены пруф? Вот цена за SSD (первая ссылка в гугле): http://www.xakep.ru/post/60422/ (почитайте кстати комменты там), в 12 году была чуть ниже 1 доллара за 1 гб.
Про стомость сборки знаю сам, поскольку собираю самостоятельно железо.
ссылка на хакер ру - это, конечно, пруф =) ты же понимаешь, что оптом и с договором о регулярных закупках на год вперед все, ммм, несколько дешевле?
советую подумать, зачем нужен ssd на виртуалках. подсказка 1: seek time. подсказка 2: стабильность disk i/o вне зависимости от соседей
xfs пользуюсь уже много лет, никаких проблем. проблемы там всегда были только у kde-шных дятлов, не умеющих программировать.
советую подумать, зачем нужен ssd на виртуалках. подсказка 1: seek time. подсказка 2: стабильность disk i/o вне зависимости от соседей
xfs пользуюсь уже много лет, никаких проблем. проблемы там всегда были только у kde-шных дятлов, не умеющих программировать.
5 баксов! 5 баксов!!! Этого недостаточно даже на бизнес ланч! А мы говорим о стабильном добротном хостинге, где аптайм, хороший канал, надо платить за оборудование, за трафик, за электричество, за инфраструктуру, налоги и оборудование... Мы говорим о VPN! Цена 6-ти ядерного ксеона (только проца) - от 15т.р., + ОЗУ + платформа. А зарплата?
Что бы окупить - нужно много клиентов, очень много.
А по поводу SSD - имхо, носитель с ограниченным сроком службы. Они должны хотя бы резервироваться по схеме 1+1 (raid 1) или по схеме n-2 (raid 6)
Что характерно я увидел только уверения, что "SAS 15k быстрей!", и "SSD УГ и ненадежны". Читать журнал на букву Х у меня нет ни малейшего желания, эти друзья себя изжили уже лет 7 назад. Тут я с Фиксером согласен на 146%. Особенно по 2м пунктам, что он привел
У SSD есть еще одно очевидное преимущество: при износе данные становятся просто рид-онли, и потеря данных с SSD имеет гораздо более редкий шанс. И не надо про рейды — видел как за три часа в пятидисковом аппаратном рейде под хорошей нагрузкой в течении часа умерли три жестяка из пяти.
Активист
Бэкап != raid. Бэкапы там есть. Мониторинг smart, уверен, тоже есть, они ж не российские хостеры, чтобы замечать проблемы только когда все загнулось
Бэкап != raid. Бэкапы там есть. Мониторинг smart, уверен, тоже есть, они ж не российские хостеры, чтобы замечать проблемы только когда все загнулось
Разумеется. Как у того же hetzner-а. Но ничего невероятного нет - посчитай сколько впсок влезет на, скажем, такую дуру, посчитай железо и каналы крупнооптовыми закупками - щас у них 250к впсок, ну к где то миллиону будет прибыль.
По ОЗУ 250 шт., по процу 200 (c учетом лояльного использования), по HDD - 16 VPS. Конечно, у них скажем NAS на 2U с 30-60 корзин 2.5'', но NAS еще отбить надо, дорогое удовльствие. MegaRaid вещь хорошая конечно, но по экспандерам упрется в производительность шины.
Ну а так, да.. 1k-5k$ прибыли могут получать, после того, как отобют все расходы.
Конечно, можно надется, что в основном будут крутиться сайтики на друпале или джумле + отсюда много ресурсов будет+ доход с суппорта.
.
Ну а так, да.. 1k-5k$ прибыли могут получать, после того, как отобют все расходы.
Конечно, можно надется, что в основном будут крутиться сайтики на друпале или джумле + отсюда много ресурсов будет+ доход с суппорта.
.
У меня недавно клиент был, так вот .. у него сайтик на джумле, захостили, у меня сервер этот - загрука 10% ресурсов (платформа Supermicro , Intel Xeon , 32G), так вот - ложил сервер практически, LA до 0.2 - 0.5 до 100. В общем.. .Методом дебага было установлено - что вешал нас именно этот клент хитрове...м скриптом на PHP, который ложил все напрочь через сетевой интерфейс, да так, что мосты не справлялись. Троян был залит на один вирутальный хост. Управлялся из центра управления. Все участники были инфицированы одним и тем же трояном, ложили друг друга, во всехда незивестное время, установить какая нода является управляемой было не возможно.
Запустил я эту хрень у себя на Core i5 760 8G - в три потока, ядро не реагировало на alt + sysrq + s, alt+ sysrq + b (emergency sync и reboot на уровне ядра, кто не вкурсе про sysrq), сетевуха судя по kernlog вызывала зависание ядра на уровне базовой системы ввода вывода (причем нагрузки на проц была на все ядра). Запустил этот скрипт и под вирутальной машиной, не помогло. Вешало все, хотя ограничил ресрсы.
Как выяснилось, интеловские сетевыхи выдерживали, а на чипсете от реалтека - вызывали аппаратные сбои.
В логах типа того:
Запустил я эту хрень у себя на Core i5 760 8G - в три потока, ядро не реагировало на alt + sysrq + s, alt+ sysrq + b (emergency sync и reboot на уровне ядра, кто не вкурсе про sysrq), сетевуха судя по kernlog вызывала зависание ядра на уровне базовой системы ввода вывода (причем нагрузки на проц была на все ядра). Запустил этот скрипт и под вирутальной машиной, не помогло. Вешало все, хотя ограничил ресрсы.
Как выяснилось, интеловские сетевыхи выдерживали, а на чипсете от реалтека - вызывали аппаратные сбои.
В логах типа того:
Код:
kernel: [382055.361594] php[32445] general protection ip:68ffa7 sp:7fffe9372cc0 error:0 in php5-cgi[400000+6fa000]
...
....
kernel: [4919784.734112] r8169 0000:03:00.0: eth0: link up
kernel: [4919788.203047] r8169 0000:03:00.0: eth0: link up
kernel: [4919788.258600] r8169 0000:03:00.0: eth0: link up
kernel: [4919794.917317] r8169 0000:03:00.0: eth0: link up
kernel: [4919795.030732] r8169 0000:03:00.0: eth0: link up
kernel: [4919805.932449] r8169 0000:03:00.0: eth0: link up
kernel: [4919965.661365] INFO: task named:18105 blocked for more than 120 seconds.
kernel: [4919965.661400] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kernel: [4919965.661429] named D 0000000000000000 0 18105 1 0x00000000
kernel: [4919965.661432] ffff88041e087100 0000000000000082 0000000000000000 ffffffffa01116d5
kernel: [4919965.661435] 0001120000000002 0000000000000000 000000000000f9e0 ffff8803ee811fd8
kernel: [4919965.661437] 0000000000015780 0000000000015780 ffff88040b453f90 ffff88040b454288
kernel: [4919965.661439] Call Trace:
kernel: [4919965.661451] [<ffffffffa01116d5>] ? r1bio_pool_alloc+0x21/0x3f [raid1]
kernel: [4919965.661455] [<ffffffff810168f3>] ? read_tsc+0xa/0x20
kernel: [4919965.661458] [<ffffffff8106bb5e>] ? timekeeping_get_ns+0xe/0x2e
kernel: [4919965.661461] [<ffffffff812fbb6a>] ? io_schedule+0x73/0xb7
kernel: [4919965.661464] [<ffffffff8117fa3d>] ? get_request_wait+0xf0/0x188
kernel: [4919965.661466] [<ffffffff81065046>] ? autoremove_wake_function+0x0/0x2e
kernel: [4919965.661468] [<ffffffff8117fdcc>] ? __make_request+0x2f7/0x428
kernel: [4919965.661470] [<ffffffff8117e59b>] ? generic_make_request+0x299/0x2f9
kernel: [4919965.661472] [<ffffffff8117e6d1>] ? submit_bio+0xd6/0xf2
kernel: [4919965.661476] [<ffffffff810d8e2c>] ? end_swap_bio_read+0x0/0x60
kernel: [4919965.661479] [<ffffffff81111a75>] ? bio_alloc+0x10/0x1f
kernel: [4919965.661481] [<ffffffff810d8c7e>] ? get_swap_bio+0x4a/0x9a
kernel: [4919965.661483] [<ffffffff810d8d1d>] ? swap_readpage+0x4f/0x53
kernel: [4919965.661485] [<ffffffff810d902a>] ? read_swap_cache_async+0xb3/0xf3
kernel: [4919965.661487] [<ffffffff810d90c1>] ? swapin_readahead+0x57/0x98
kernel: [4919965.661490] [<ffffffff810ccf41>] ? handle_mm_fault+0x47f/0x80f
kernel: [4919965.661493] [<ffffffff812ff306>] ? do_page_fault+0x2e0/0x2fc
kernel: [4919965.661496] [<ffffffff812fd1a5>] ? page_fault+0x25/0x30
kernel: [4919965.661501] INFO: task atop:16193 blocked for more than 120 seconds.
kernel: [4919965.661520] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kernel: [4919965.661550] atop D ffff8800b932bf90 0 16193 1 0x00000000
kernel: [4919965.661552] ffff8800b932bf90 0000000000000086 0000000000011210 ffffffffa01116d5
kernel: [4919965.661554] 0001120038323530 0000000000000000 000000000000f9e0 ffff880233d0dfd8
kernel: [4919965.661556] 0000000000015780 0000000000015780 ffff88041b45a350 ffff88041b45a648
kernel: [4919965.661558] Call Trace: