Игорь Фролов недавно подкинул ссылочку (спасибо, Игорь!) на утилитку, которая дополняет собой обычный маковский top. Линуксовым топом я могу пользоваться вполне комфортно, а вот от топа на маке у меня болит в разных местах. Зачем всё так сложно, когда иногда надо проще, найти и убить например или посмотреть кто сейчас всё съел. Вот утилита vtop от James Hall как раз настолько простая, насколько это нужно. Правда, для её установки понадобится иметь уже установленный node.js
Сама установка очень простая (см. ссылку выше)

sudo npm install -g vtop

Выглядит vtop в консоли примерно так

В навигации vtop-а ощущается легкий Vim-о флер, что придает ему известной ламповости.

Есть такая приблуда forever, если говорить коротко о её назначении - логирование ошибок и автоматический перезапуск приложения после его падения.
Собственно эта заметка о том как перезапускать приложение при помощи forever, если рядом запущено ещё одно приложение с таким же именем запускающего приложение скрипта. Обычно проще всего убивать по имени, но вот так получилось что имена скриптов у меня перекрылись и перезапуск одного приложения стал вызывать смерть других. Логично, на помощь приходит uid, который позволяет каждому приложению присвоить понятно что, и таким образом решить "проблему" с уникальностью имен скриптов, запущенных одновременно на одной машине.
Пример скрипта для перезапуска приложения по uid

#!/bin/bash
APP_DIR="/home/user/app-folder"
FOREVER="/usr/local/bin/forever"
APP_UID=appUniqUid
DAEMON=$FOREVER" --append --uid $APP_UID start --spinSleepTime 10000 --minUptime 1000 --sourceDir "$APP_DIR
APP_SCRIPT="app.js"

## vars for app env
export APP_PORT=4433
export NODE_ENV=production
####

echo -n "Stopping $APP_SCRIPT: "
$FOREVER stop $APP_UID && echo 'ok, stoped' || echo 'error on stop node app'
echo -n "Starting $APP_SCRIPT: "
$DAEMON $APP_SCRIPT && echo 'ok, started' || echo 'error on start node app'

Теперь в консоли можно выполнить

forever list

и увидеть искомый uid.
Зачем это вообще надо, ведь forever сам должен уметь перезапускать всё и после деплоя и после падения?? Должен, да, но вот бывает такая фигня, когда после деплоя взлетает всё криво, или по каким-то другим причинам приложению требуется насильная перезагрузка. А вспоминать как там рулить forever в таких случаях мне лень. Я лентяй, поэтому я написал этот скриптик.

На самом деле эта заметка почти никакого отношения к node.js не имеет, сам по себе такой перезапуск может быть чего угодно и вообще есть другие варианты, но я как совсем ленивый гражданин не мог не воспользоваться такой халявой.
Суть такая: есть приложение которое должно автоматом взлетать после перезагрузки и поскольку в некоторых случаях (весьма неприятных) проконтролировать перезагрузку невозможно, надо прописать это приложение где-то на автозапуск. Использовать для этой цели (оказывается!) можно тот самый crontab. Я вожусь с линуксом уже лет 6-7 и понятия не имел о такой замечательной возможности. Есть два момента

1. Нужно выбрать cron того пользователя от которого должно заработать ваше приложение
2. Нужно воспользоваться простой как двери в милиции инструкцией @reboot

Итак, идем редактировать crontab для выбраннорого пользователя так

crontab -e -u user_login

Теперь добавляем наше распоряжение на действия после перезагрузки, например так

@reboot sleep 20; /home/user_login/restart-app.sh

В примере через 20 секунд после перезагрузки будет запущен выбранный скрипт. И вся любовь. Задержка взята по причине того, что какие-то сервисы у меня не стартовали до запуска искомого приложения и оно валилось не находя нужной для себя фигни. С такой задержкой все взлетает на ура.

Столкнулся с багой оригинального характера. Когда написал свою первую прокладку под mysql сильно радовался тому, что все работает и довольно привычно-удобно. Но оказывается я страшный лошара. В этой самой прокладке есть метод foundRows который должен возвращать (и это иногда работает!) количество рядов в запросе без учета LIMIT (см. FOUND_ROWS()). Загвоздка в том что FOUND_ROWS() сработает только для того запроса который был перед ним в пределах одного коннекта. То есть сначала запрос на select с лимитом и следующим обязательно должен быть select found_rows() примерно так

SELECT SQL_CALC_FOUND_ROWS * 
FROM tbl_name
WHERE id > 100 
LIMIT 10;

SELECT FOUND_ROWS();

В ситуации с асинхронными запросами, когда используется только один коннект, при приличной паралельной загрузке между этими двумя запросами вполне может проскочить другой запрос и FOUND_ROWS() начнет "врать". По сути очередь будет выглядеть так

SELECT SQL_CALC_FOUND_ROWS * 
FROM tbl_name
WHERE id > 100 
LIMIT 10;

# пример "проскочившего" запроса
SELECT *
FROM tbl_name_2
WHERE id=12;

SELECT FOUND_ROWS();

И вот уже FOUND_ROWS() возвращает совершенно не то что нужно. Для создания тестовой загрузки проекта можно пользоваться Apache ab например вот так

# 900 раз запросить страницу с 10 конкурентными запросами
ab -c 10 -n 900 http://cocainum.info/post/301/

В моей ситуации во время такого тестирования мелкие запросы как раз влезали между запросами с лимитом и запросами подсчета рядов. В результате пейджинг думал что страниц у него ровно одна штука и исчезал со всех своих страниц как класс, пока шла нагрузка с конкурентными запросами.
А теперь внимание вопрос для третьего класса средней школлы.. Как поделить три яблока на четверых чтобы каждый получил по яблоку и никто не получил по лицу. Как же это решить? Я не нашел удобного толкового решения. Callback hell забарывает и на код становится жутко глядеть. Решение есть, смотрим тут Pooling connections. То есть если необходимо по каким-то причинам строго последовательно выполнять запросы, то из пула специально берем отдельный коннект и пользуемся им. Выглядеть это будет примерно так:

pool.getConnection(function(err, conn) {
  conn.query( 'SELECT SQL_CALC_FOUND_ROWS * FROM tab1 LIMIT 100,10', function(err, rows) {
    conn.query('SELECT FOUND_ROWS() as cnt', function(err, rows){
      // получаем общее кол-во строк
      // ...
      // освобождаем соединение
      conn.release();
    });
  });
});

В прокладке я это реализовал, но пока что выглядит все это жутко, надо либо свыкнуться с этой мыслью, либо придумать что-то лучше. Пока переделанную версию выкладывать смысла нет по-моему.
Стоит обратить внимание на секцию настроек "Pool options" хотя бы чтобы научиться регулировать количество соединений connectionLimit.
Вообще доделать конечно надо ради интереса, но по-хорошему надо переезжать уже на Sequelize или что-то такое.

О том что такое Grunt и зачем он нужен в общих чертах расскажет статья "Grunt для тех, кто считает штуки вроде него странными и сложными".

Бьюсь об заклад, вы наверняка уже что-то слышали про Grunt. Что ж, Grunt — это, по сути, планировщик задач. Grunt может делать все эти задачи за вас. Стоит лишь установить его, что, кстати, не так уж и сложно, и эти операции будут происходить автоматически, так, что вам про них даже не придётся вспоминать.

© frontender.info