Можно ли заставить работать elasticsearch на 512 RAM?

Question

[Nicle]

Собственно вопрос в том, что при 512 RAM elasticsearch падает при попытке сделать поиск.
Использую VPS за 5$ на DigitalOcean.

Answer 1

[Пума Тайланд]

доплатить 5 баксов, все таки мир джава не для хомячков.

Comments

[Nicle]

На самом дело принципа попробовать настроить. На текущий день лишние 5$ дороговато обходятся людям с рублевым оборотом.

[Пума Тайланд]

Nicle: попробуйте что нибудь в рублевом эквиваленте например vdsina.ru самый дешёвый вариант ну ещё машинку желательно 32 битную запускать ну и лимиты джавы закрутить на минимум

[Nicle]

Пума Тайланд: На самом деле только съехал с русского хостера, хотелось попробовать что-нибудь зарубежного, посмотреть как они относятся к клиентам. Может знаете где посмотреть толковую настройку java?

[Пума Тайланд]

Nicle: при массовом хостинге у всех отношение к клиентам никакое , это не зависит от страны.

[Игорь Воротнёв]

Пума Тайланд: ну не скажите, есть приятные исключения, и DO - одно из них. Отношение что к моему личному аккаунту с 1м VPS за $10, что к моему рабочему аккаунту с 26ю серверами на круглую сумму в месяц - одинаково хорошее, оперативное и качественное. Я на личном акке даже однажды тестировал - убрал деньги с карты, чтобы автобиллинг не проходил, и ждал что будет дальше. 24 числа следующего месяца (только через 3,5 недели!) мне написали, что с моим банком проблема, и предложили вместе поискать другой способ оплаты и вообще любую помощь в решении проблемы. Я им наплел, что жду платеж на карту от клиента в течение 3-4 дней, они пошли навстречу и вручную вынули мой сервер из автоблока, дав мне еще неделю времени на оплату. И никаких проблем с аптаймом, блоками и тд. Вот это - хороший сервис. Про реальную помощь в самых разных ситуациях на клиентских серверах я вообще молчу. Если честно, сервис DO - одна из лучших сторон. Даже если появится конкурент, который будет продавать такие же сервер в 2 раза дешевле, я не уйду. Ибо сервис - отличный.

[Пума Тайланд]

Игорь Воротнёв: блин да плевать мне на отношение хостера ко мне, лишь бы работало, идеальный сл3учай, когда я могу сам всем рулить и не использовать суппорт.
По сути из явных проблем, которые есть и не решились на цифровом океане.
1)Долгий старт или рестарт дроплетов, 30-60 минут да запросто, а че сайт подождет.
2)Зави сание дроплета во время его бекапа на стороне цифрового океана, а че выключите бекапы и сами себя бекапьте, очень веселый ответ техподдержки.
До сих пор цифровой океан не подходит для серьезных проектов к сожалению, понятно что 99 процентам сайтов поваляться в дауне один день в месяц вообще не проблема.

[Игорь Воротнёв]

Пума Тайланд: Ну как раз я про остальное не упомянул даже, так как там проблем не возникает, DO как раз из тех, что "включил и забыл" - все просто работает, как техника Apple. По твоим случаям:
1. Ни разу не было, а под моим контролем много дроплетов разного размера в разных датацентрах (чуть больше 40, плюс регулярно создаются-удаляются временные для тестов и тп). Если ребут больше 1 минуты - либо проблема с настройками сервака при загрузке, либо реально с железом (иногда случается). В первом случае - это ваша забота, во втором - пишите в саппорт, решат быстро (проверено).
2. Все дроплеты бекапятся, ни разу не было ничего подобного. Я вообще не замечаю даже существование этой фичи, она "просто работает".
Не обобщайте на своем негативном опыте (тем более без объективных доказательств, что вина на стороне DO). Под моим контролем там более 40 серверов, все они мониторятся через New Relic. Аптайм практически равен 100%, единственный даунтайм - это когда мы сами ребутим серваки, например после апдейтов.

[Пума Тайланд]

Игорь Воротнёв: ну понятно что не каждый раз такое происходит, но оно есть и суппорт этого не отрицает и говорит да такое может произойти.
Просто есть у меня скажем проекты на которых даже минута простоя смерти подобна.

[Игорь Воротнёв]

Пума Тайланд: Вообще-то для проектов где минута простоя смерти подобна нужно делать fail-proof решения, с репликацией бд и балансировщиком :) Пруф что "суппорт говорит да такое может произойти" есть?

[Пума Тайланд]

Игорь Воротнёв: вот ответ про бекап например
Reply From Kanderson (Support Team)07/24/2015
Hey there,

Thanks for the update.

It looks like a backup took place about that time. The backup process was started automatically as the droplet is configured to have backups set. While it's unclear exactly how the droplet stopped becoming responsive, there is a possibility that disk i/o contention may have occurred on the droplet as a result of activity on the droplet itself and reading for the completion of the backup.

If this has happened before on this droplet or others, you may want to consider using an alternative backup method such as those listed in these community articles:

https://www.digitalocean.com/community/articles/ho...

https://www.digitalocean.com/community/articles/ho...

https://www.digitalocean.com/community/articles/ho...

We will continue to monitor this for further issues.

Best,
Keith
Platform Support
Check out our community for helpful articles and tutorials.
https://digitalocean.com/community

[Пума Тайланд]

Про долгий старт или рестарт они просто отвечают через несколько часов, мы видим у вас все хорошо.

[Игорь Воротнёв]

Пума Тайланд: ну и где здесь в тексте утверждение "да такое может произойти" (по крайней мере по вашим словам я уловил контекст "ну это типа нормально, бывает, не парьтесь")? Вам четтко написали:
1. Возможную причину
2. Что делать
3. Пообещали мониторить ваш дроплет на предмет залипания
Абсолютно корректный и адекватный ответ. Вообще, в данном случае, если проект критичен к аптайму - создать новый дроплет и перенести все на него (хотя, как я уже говорил выше, для совсем критичных проектов, нужна схема fail-proof). Хотя я бы не делал, если подобное не повторится. Ну и, судя по озвученной возможной причине, произошел конфликт I/O, что вполне может случиться с write-intensive приложениями. В данном случае, дейсттвительно, стандартный backup попросту не подойдет. В подобных ситуациях как раз и помогает fail-proof архитектура - на время бекапа сервера он исключается из цепочки, передавая свою функцию вторичному, после бекапа возвращается в строй.

[Пума Тайланд]

Игорь Воротнёв: Наверно потому что это происходило несколько раз в одно и тоже время )))
Да конечно выключите наши бекапы и делайте их сами как хотите, отличнейший совет, а вообще можете ещё сделать свое облако.
Да я тоже всегда всем обещаю мониторить, тут ничего удивительного.

[Пума Тайланд]

Игорь Воротнёв: это мелкий дроплет для фильтрации трафика, там данных копейки и толкьо в /etc
мне там нахрен по сути ничего не надо и я могу за пять сек поднять такой же, просто лень с этим возиться и на всякий случай если что сдохнет использую на нем бекапы от цифрового океана.

[Игорь Воротнёв]

Пума Тайланд: ну как бы да. Если вам нужен надежный бекап - делайте свой. Родной бекап - это банальный фоновый снимок. Из документации, например - "Please note that automated backups running on a server with an active database can result in an incomplete backup of your database." То же самое касается активной записи в файловую систему. Тут, как бы, изначально хостер говорит, что наш автобекап - штука не совсем надежная, если вам надо что-то большее, чем просто регулярные снимки - используйте кастомные решения (которых масса).

[Пума Тайланд]

Игорь Воротнёв: ну я прекрасно понимаю что там не консистентности на определенных вещах, но совершенно не приемлело падение дроплета на процессе их бекапа, я бы даже не сильно растроился если бы они сделали ребут в таком случае, а так просто дроплет упал пока сам ручками не поднимешь.

[Игорь Воротнёв]

Пума Тайланд: ну право же :) это софтверная проблема, не железная. При чем тут хостер, если за софтовую часть VPS он не несет ответственности? Для мониторинга и ребута сервера / ребута или убивания процесса / рестарта процессов используйте соответствующие тулзы - Monit, Cactus, New Relic и иже с ними. То, чего вы ожидаете в этой ситуации - возможно. Но такой сервис называется Managed VPS. Вот в этом случае вы платите им деньги за мониторинг и администрирование и железа, и софта. Ну вы и сами в курсе. Я понимаю, что необходимость дополнительных телодвижений напрягает, но это обратная сторона медали. Не хотите ничего делать - берите Managed, хотите дешевле - берите self-managed и делайте все сами.

[Пума Тайланд]

Игорь Воротнёв: так это софтверная проблема хостера, я то тут причем, я даже толком не имею доступа к его бекапам, а тем более его системе.
Ну а чего перезапускать то если дроплет умер с концами?
Мне не нужен манаджед впс. Я всего лишь хочу в момент когда дигитал ошен запускает свою систему бекапа на мой дроплен он не умирал без всяких признаков жизни.
То есть я должен ещё и приплатить за чудесний сервис заключающийся в том что дроплет может зависнуть в любой момент из за проблем на стороне хостера, ну это же глупо совсем.

[Игорь Воротнёв]

Пума Тайланд:
1. "хочу в момент когда дигитал ошен запускает свою систему бекапа на мой дроплен он не умирал без всяких признаков жизни" - выключите автобекап, используйте свое, более контролируемое решение.
2. "приплатить за чудесний сервис заключающийся в том что дроплет может зависнуть в любой момент из за проблем на стороне хостера" - это не проблема на стороне хостера, это how it works, о чем хостер предупреждает изначально (читать доки надо перед включением опции бекапа). Для большинства простых серверов этот вариант подходит и работает. Для особых случаев, как ваш - выключайте и делайте свою бекап-рутину. Денег заодно сэкономите.
И вообще. Суточный / еженедельный бекап в виде снапшота, если честно, абсолютно ненадежная система бекапа. Если у вас есть критичность данных - этот вариант изначально не подходит. Вы должны иметь живую репликацию БД, чтобы ни одна транзакция не потерялась (а при суточном снапшоте вы же потеряете все данные за время с момента последнего бекапа до фейла). Это первое и основное. Код, естественно, на CVS. Файловая система (аплоады, например) не столь критичны обычно, но если и в них есть что-то критичное - используйте свою автоматическую синхронизацию, зеркалирование. Ни одна стандартная система backup'ов по расписанию не подходит для случаев где нужна надежность и актуальность бекапов. Не пытайтесь участвовать в гонке Формула-1 на обычном городском хетчбеке, пусть даже тюнингованом. Это совершенно разные вещи.

[Пума Тайланд]

Игорь Воротнёв: да я же сказал что у меня нет там важных данных, там просто система фильтрации ддос атак с динамическими правилами под ситуацию.
Вообще ситуация что включение какой то опции в админке приводит к зависанию дроплета не приемлема изначально.
Если уж и делать свой бекап, то мне проще тогда уж просто перенести дроплет в свое облако и у меня там когда запускается внешний бекап инстансов, ничего не падает по сравнению с дигитал ошеном.

[Игорь Воротнёв]

Пума Тайланд: ладно, проехали. Бесполезный спор, так как вы упрямо не замечаете, что проблема не столько в бекапе DO, сколько в ваших ожиданиях, которые не соответствуют этому решению. Вы хотите и ожидаете, чтобы было так, как вы хотите, но на самом деле то там все иначе. Проблема будет существовать, пока ваши ожидания будут завышены и оторваны он реальности.

[Пума Тайланд]

Игорь Воротнёв: Может я чего то не понимаю, но наверно это нормально ожидать, что если я поставил галочку бекап, то я ожидаю что он просто работает. У других же работает, а тут падает )

[Игорь Воротнёв]

Пума Тайланд: ну это нормально для обычного юзера (у которого и задачи примитивные). А для продвинутого норма - сначала почитать доку, чтобы понимать как эта фича работает. И только после этого принимать решение - ставить галочку или нет. Тем более что галочка обходится в 20% от стоимости дроплета.

[Пума Тайланд]

Игорь Воротнёв: да меня мало волнуют лишние 20 баксов, но в доке про зависание ничего не написано, там написано включи и будет работать, да не гарантированный бекап, но что оно при этом уронит дроплет ничего.

Answer 2

[Denis Goltsev]

Беглый поиск навел сюда https://gist.github.com/dominicsayers/8319752

Comments

[un1t]

Кто попробует, отпишитесь, интересно узнать работает ли.

[MintTea]

un1t Я пробовал, и да, отдельные строки в том гисте в тему, но их недостаточно

[Nicle]

Попробовал. Разные настройки конфигов. Все равно валится.

Answer 3

[MintTea]

В общем и целом, можно. У меня есть подтвержденный пример одновременной работы трех инстансов (мне надо было именно три отдельных инстанса, да) в virtualbox'е с 1024 мб памяти, работало стабильно. Получалось где-то по 200мб на каждый инстанс.
Естественно, с ростом размера индексов, этого не будет хватать, поэтому вам будет проще купить более мощный сервер.

Answer 4

[Дмитрий Полушкин]

Вполне. Правда, зависит от кол-во данных, по которым вы будете искать и хотите индексировать.