Проблема в том, что я наверняка не знаю, что у меня жрет ресурсы. Сервер (VPS) при не очень высокой нагрузке более-менее нагружен. И у меня есть подозрение, что это связано с логированием (возможно, это и есть стадия "логи начали влиять на производительность"), но я в нем не уверен (возможно, другие части приложения грузят базу, и база тормозит не потому что загружена логами, а по иной причине).
Можно ли как-то посмотреть/сравнить сколько ресурсов отжирает работа с каждой таблицей?
Погляжу, спасибо, но предварительно эта идея кажется оверкиллом. Логи в моем случае очень маленькая и не очень важная часть приложения, и разворачивать целый стек ПО для этой задачи - "ну такое"...
Примерно как для шелл скрипта вся схема логирования - это код: echo `date` message >> $LOG
Тут, мне кажется, проблема не с CORS а с OPTIONS. Запрос на OPTIONS возможно не доходит от вебсервера до этого куска кода. Под каким вебсервером крутится это приложение? Может быть такое, что код исполняется только для методов GET/POST но не для OPTIONS?
RoffDaniel, bad ownership or modes for chroot directory component "/var/kov-mc/"
Вот и ответ. Надо медитировать на тему владельца-группы и прав доступа /var/kov-mc/
В целом, я с вами согласен, это все разумно. Но вот в моем случае, похоже, не подойдет:
1. Stress тест
Приложение сейчас хостится на VPSках. Соответственно, тут две стороны - с одной, на дешевой VPS в предел производительности мы точно можем упереться довольно легко. С другой - всегда есть решение в виде простого апгрейда тарифа на более мощную VPS. (Но мне, технически, конечно хотелось бы заранее знать, что архитектура у меня такая, что масштабироваться будет легко, даже когда дальше уже некуда апгрейдиться). А вот stress-тест сделать на облачной базе - можно ли? Или выйдет достаточно дорого (ведь нужно ее забить огромными объемами) ?
2. Read Only запросы
Увы, приложение по большей части собирает данные. Конечно, иногда и отдает тоже, но в обычном случае, наверное, на 100-1000 read есть один write, а у меня наоборот.
Хотя кто потом будет читать этот вопрос, для них это, возможно, будет правильными советами, сам так считаю.
Согласен с вами, про идею. Поэтому и не планирую продавать ее, вряд ли кто-то купит.
Деньги - это мотивация, да. Но не единственная. Мое имя есть в исходных кодах ядра ОС Linux, участие в других известных проектах и это серьезно помогает при поиске заказчиков. Участие в интересном проекте - всегда плюс. Помните, был такой проект, Chatroulette. Сколько он принес денег? Да вроде нисколько. Но он интересный и он создал имя (раз даже NY Times написали и в South Park спародировали). Молодой программист который после ВУЗа уже может сказать "я был основным программистом для этого интересного проекта" - получает серьезное преимущество.
Почему вы считаете, что цель должна быть обязательно измеряемой, чтобы человек заинтересовался? Это в постановке задачи, задача должна быть обязательно измеряемой (чтоб было понятно, достигли цели или нет), и как вариант, измерять можно через аудиторию проекта, но как proof-of-concept, доказательство, что человек действительно освоил технологии - достаточно проекта с 1 пользователем. Это уже имеет ценность ведь. (Хотя миллион - конечно лучше).
А вот насчет бумажки - презентации, да, отличная идея, лучше чем каждому сумбурно ее пересказывать, забывая иногда некоторые важные моменты.
В принципе - да. Если программист не камень, который нужно через силу тащить и пинать, то его юношеский энтузиазм иногда нужно поднаправить только. Ну, например, объяснить, что вот тут данные надо не напрямую передавать, а через openssl тоннель, что для хранения таких данных лучше не SQL базу, а No-SQL итд. По себе знаю, что очень часто какой-то важный совет состоит из одного слова, которое надо загуглить или провикипедировать и сразу наступает озарение и меняется видение проекта.
Фактически - это же получается просто общение с коллегами на общую интересную тему, а не работа, вот как мы сейчас бесплатно общаемся свое время - просто из интереса. Поотвечать на письма иногда и может раз в 1-2 недели попить кофе-пиво обсуждая это вживую - почему бы и нет?
Ну и отчасти мотивация в этой смене задач, смена деятельности, поиграться в это - с малыми рисками посмотреть, насколько можно минимизировать свое время контроля проектом. Вдруг да получится? А если и нет - ну невелика беда, можно заново проект начать или просто похоронить его.
Даже копейки жалко (это своего рода забава для фанатов, а не инвестиции), и не то отношение к проекту. Я бы скорее предпочел молодых энтузиастов, которым не нужно денег, у которых есть энтузиазм, но при этом они могут срывать сроки и иметь долгий learning curve, для фанатского проекта это не проблема.
Александр Маджугин, мне понравилась эта идея (хотя и через задницу, но вполне рабочая же!). Только, надо, наверное, не bash а busybox, потому что bash не сможет даже ps запустить, если памяти нет, а в busybox они встроены все. Хотя, блин, malloc() то все равно вызывают - может и упасть, наверное.
Дмитрий Александров, я понимаю что вы хотите донести. И я спрашиваю про другой (гораздо более сложный) путь, не потому что простой, прямой и короткий путь мне не нравится, а именно наоборот - именно потому что он мне полностью понятен, зачем мне отвлекать тут людей вопросами, на которые я знаю ответ? Это не ситуация или/или. Сервер уже ребутнули, логи начали копать, итд. (как бы, простуду вылечили до следующего раза традиционными понятными средствами)
Просто эта проблема (моя частная, локальная и понятная) меня натолкнула на мысль о более глобальной мировой проблеме, с которой все изредка сталкиваются (невозможность удаленно зайти на сервер) и вот эта ситуация технически у меня вызывает больше интереса и желания понять ее :-). (хочется понять, есть ли универсальная вакцина от этой простуды)
Да в другом дело. С сервером (с частной проблемой) уже решилось все. (перегрузили и зашли).
Суть моего вопроса про ОБЩУЮ ситуацию - как сделать когда у меня или у вас или у кого-то еще будет какая-то задача, которая отжирает память - как сделать чтобы SSH работал? Предотвратить OOM в мировом масштабе - задача заведомо невыполнимая. А вот сделать так, чтобы по SSH можно было зайти даже когда на сервере OOM - это вполне решаемо. (и мне немного странно, что до сих пор это никем в мире не сделано).
Как один из вариантов - вот cgroups выше предложили. А у меня была мысль, может быть как-то можно пре-аллоцировать мегабайт 10-50 для SSH, чтобы рут всегда мог зайти и запустить ps, kill итд
В частном случае - конечно.
Но у меня в жизни не первый раз, когда сервер живой, а достучаться не могу. Поэтому хочется в общем случае решить эту проблему.
Александр +, так нужна подмена DNS, а не перехват HTTPS. Для девелоперских задач - это вполне подходит. На новом сервере, на который я переправляю example.com - стоит валидный сертификат для example.com. (в общем, все так же как с /etc/hosts - прописываю новый и работает же). Вот перенаправить гугл таким образом - другое дело, там уже https должен ругаться и пусть ругается.
Сниффать пароли можно и сейчас, например, FoxyProxy перенаправляет трафик же на любые прокси-серверы (которые в HTTP могут сниффать пароли).
Александр +, работает для HTTP, но не работает для HTTPS (хотя на сервере сертификаты соответствуют, при смене адреса в hosts - все тесты проходят. Ну и по отзывам, на HTTPS ни у кого не работает).
Странно немного, почему нет такого расширения (чтобы и HTTPS работал). Может в самом деле API не позволяет? Версия из первого ответа (про безопасность) мне не кажется правдоподобной, т.к. аддоны вроде foxyproxy работают, так что это не противоречит концепции безопасности.
Можно ли как-то посмотреть/сравнить сколько ресурсов отжирает работа с каждой таблицей?