Max Payne

В общем, на сколько я понял, память у меня и не текла.

Проблема в алгоритме, который в методе parse() и настройках, которые я использовал для парсинга. Значения конкуретных запросов и тредов у меня слишком высоки, а значение DEPTH_PRIORITY было установлено по-умолчанию (0).

Таким образом получалось, что страницы поиска парсились быстрее, чем генерировались айтемы на основании записей с них, создавалась длинная очередь и память переполнялось. Помогла установка значения DEPTH_PRIORITY = 1.
Однако скорость парсинга, к сожалению, снизилась.
Старт двух спайдеров в двух разных процессах немного улучшил ситуацию.

groups.getTokenPermissions

У VK CallBack Endpoint'a нельзя указать порт, то есть все запросы будут идти на 80-й в любом случае. Дальше на своем сервере можете проксировать куда угодно.

Во-первых, почитайте про vk callback api. На основе асинхронного веб-сервера типа aiohttp или tornado будет очень быстро.
Во-вторых, на сколько я понял, вы хотели использовать список вместо очереди. Не нужно. Если уж использовать, то хотя бы queue.Queue.
В-третьих, первый вариант явно провальный, будет работать не очень круто, если даже заставите хоть как-то работать. Второй вариант выглядит более логичным, если всё таки решите использовать лонгпулл, но здесь без многоточности/многопроцессорности, думаю, не обойтись.

В итоге: если делать через лонгпулл самый простой вариант - один процесс/поток с бесконечным циклом, который делает await session.get(longpoll_url).json(), далее ЛИБО добавляет задания в очередь для хендлера, который работает во втором процессе с таким же бесконечным циклом, ЛИБО порождает новый поток/процесс для каждого нового сообщения. Но здесь сразу же, даже до этапа проектирования, видно много узких мест. Если делать через колбек - узких мест, фактически, нет. Например, многопроцессорный асинхронный торнадо (но уступающий в однопотоке по-умолчанию асинхронному aiohttp), справится с любой нагрузкой, узких мест нет, он, по сути, сам в своих потоках/процессах будет разгребать новые запросы, вам об этом думать будет не надо.

Предыдущий агрессивно-бесполезный оратор удалил свой ответ порекомендовав мне, как очень умному, ответить за него:

Сервисы ВКонтакте - не что иное, как новомодные VK Apps.
BackEnd для них можете написать на чём угодно, хоть на python, хоть на PHP, хоть на node.js. НО, вас скорее интересует как делать такие же интересные одностраничные приложения, как в примерах по первой ссылке? Так вот, альтернатив Javascript'у в FrontEnd попросту нет.
Поэтому только с использованием Python и его фреймворков что-то сделать да можно, но вы ведь понимаете, что таким образом у вас фактически будет отсутствовать вменяемый фронтенд, а подобные приложения ориентированы в первую очередь на удобство для пользователей, красоту и одностраничность - когда передвижение по нему выполняется без перезагрузки. Без фронтенда так не получится, а фронтенд - это javascript.

Отправить пустой buttons.

Во-первых, messages.get давно устарел. Во-вторых Messages.API недавно закрыт для пользовательских страниц.

How to get a token and channel ID for Discord

Решилось добавлением аргумента mode у tornado.neturil.bind_unix_socket

server.add_socket(tornado.netutil.bind_unix_socket(self.PATH_MASK.format(0), mode=755))

Спасибо Pavel Denisov, не допёр бы что с правами что-то не то.

p.join() в данном случае сработал, но это не даёт понимания почему трейсбеки не возвращаются :(

Можно сразу в LIMIT указать (page-1)*onpage, onpage + 1, и если rowCount больше onpage — выводить Next, в ином случае (если равны или меньше) — нет.
Далее уже делать срез из полученных строк, отсекая этот элемент со следующей страницы.

Это никакое не извращение, логичное и наиболее верное решение, на мой взгляд.

Есть и решение с другой стороны:
В случае, когда количество постов уже совпало - сделать ещё один запрос, получить auto_increment (если вы его используете) и сравнить его с идентификатором последней полученной строки.