память в линукс

Use Solaris, Luke.

ulimit -u

max user processes

О, сирожи новиковы размножаются. По факту есть очень мало задач где в питоне оправданы 1000 потоков. И твоя не из таких, инфа 100%.

Что бы был смысл от 1000 потоков тебе нужно 1000 ядер, так?

Дели свою работу между меньшим количеством потоков.

Ну или просто возьми язык с поддержкой легковесных потоков (haskell, go, ...) и наплоди их хоть миллион.

Что бы был смысл от 1000 потоков тебе нужно 1000 ядер, так?

Если бы, в питоне каждый поток — это нативный поток OS, но при этом в каждый момент выполняется только один.

Разве GIL ещё не выпилили? Это точно 2015?

ulimit -u 3094205

во что ещё может упираться? мне надо понять принцип и причину, а не придумать иное решение какой-то задачи

в питоне каждый поток — это нативный поток OS, но при этом в каждый момент выполняется только один.

типичное заблуждение.

читай внимательнее про то как работает GIL .. ну или вот тут глянь (про C-API) https://docs.python.org/3/c-api/init.html#thread-state-and-the-global-interpr...

ну или возможно ты хотел сказать что *математические_операции* (числодробление) которое находится внутри Python-нитей не будет параллелиться (будет выполняться математическая операция только внутри одной Пайсон-нити в единицу времени, а остальные будут ждать).

это. да. Пайсон не параллелит математику, так как вся математика находится внутри GIL .

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

И не выпилят. Для Ъ многопоточности без гила есть модуль мультипроцессинг. Для io-bound - асинхронность через asyncio и прочих.

В раби, кстати, тоже гил, и у них тоже 2015 год.

Ну да, конечно, можно и так и даже так, только это не то чтобы пистон. Если мне не изменяет память, для 3 обещали запилить VM. Давно так.

вот простой тест

#!/usr/local/bin/python3
from threading import Thread
from concurrent.futures import ThreadPoolExecutor, wait

import threading, time
threading.stack_size(32*1024)

executor = ThreadPoolExecutor(max_workers=1000)

def _worker(i):
	while True:
		print('thread {}'.format(i))
		time.sleep(5)

for i in range(1000):
	future = executor.submit(_worker, i)

на моем компе этот код создает 1000 потоков без проблем

на слабом сервере тоже

а вот на другом сервере валится «can't start new thread» на 382 потоке

если изменить размер стека с 32*1024 на 64*1024 - создаст только 310 потоков

ulimit весь детально сравнивал - на проблемном сервере все показатели совпадают или превышают показатели рабочих серверов

Вот как понять, что мешает именно на том сервере?

/me представил 1000 процессов пайтона

а тестовый код на яве нормально создает 1000 Threads получается что-то не так с питоном? или всё же с сервером?

shared libraries + (u)ksm + zram/zswap

установил python3.5, на нем та же проблема

shared libraries + (u)ksm + zram/zswap

как я понял, zswap это экспериментальная фича для кеширования страниц для её включения предлагают прописать параметр в меню grub, вот только на vps в /boot/ пусто. Ну можно ещё покопать

а shared libraries как понимать?

Мне всё же кажется что сервак надо не тюнить, а исправлять имеющуюся проблему. Т.к. на другом сервере с более скромной конфигурацией всё запускается без проблем.

Золотые слова! Еще чуть чуть и допрешь что проблема в количестве потоков.

Подумай зачем тебе вообще 1000 потоков? Что ты этим хочешь решить? Может тебе вообще стоит посмотреть в сторону акторов/корутин?

А ты что думал? Это норма. И на руби норма, который кстати жрет не меньше питона. И 1000 и 100500. Вот такие дела в инновациях, да.

В каком месте это норма? Это сколько надо на 1000 копий пизтона?

Не понимаю что тебя так удивляет. Надо 1000 потоков без GIL'а - запускают 1000 инстансов через мультипроцессинг. Не надо - не запускают.

Ты бы лучше спросил где это надо 1000 потоков, и что там за сотона происходить будет. Обходят гил мультипроцессингом только для числодробилок. Для всего остального - асинк и трединг с минимальным оверхедом.

Ты вообще себя то понимаешь? Ты выше написал, что 1000 «инстансов» это норм, я сказал что все это гавно. А щас срешь тем же, что я написал выше.
Удачи.

Надо 1000 потоков без GIL'а - запускают 1000 инстансов через мультипроцессинг. Не надо - не запускают.

Ты наркоман, путаешь теплое с мягким. Еще раз процитирую.

Надо 1000 потоков без GIL'а - запускают 1000 инстансов через мультипроцессинг. Не надо - не запускают.

Какие альтернативы мультипроцессингу для числодробилки? Никаких. Поэтому запускать инстансы - норма. А 1000 тру-потоков - не очень, хоть на питоне, хоть на чем.

числодробилки

питон, 1000 инстансов, гуляй короче
p.s. разговор окончен, я тут не собираюсь спорить пол дня с тобой

Ко-ко-ко.

Стек заканчивается? Или питоньи треды таки волшебные?

Если его не ставить (системный ulimit -s 10240), тогда он начинает неистово жрать память - 30 потоков занимают уже 400 мб VIRT

А как ты связал память и virt. Что значит неистово жрать?

А как ты связал память и virt

virt это тоже память, пусть и виртуальная

Что значит неистово жрать?

ну с ручной установкой размера стека каждый поток увеличивает VIRT скажем на пару мегабайт, а без установки, как я написал, 30 потоков - это уже 400 мб.

У меня вот такой теоретический вопрос. Скажем, поставил я stack_size 64*1024, начал запускать по очереди пресловутые 1000 потоков.

Каждый поток получает свой собственный стек, размером 64 кб.

Но на 380-ом потоке начинаются ошибки can't start thread

Что в системе заканчивается??

У неё что, отдельная память на эти стеки? Обычная оперативка почти пустая, сколько там доступно VIRT - хз, но если она раньше достигала 3 гб, то явно 400 мб это ещё мало.

Кто-нибудь может объяснить сам принцип, что там такое происходит. Что питон пытается сделать, создавая новый поток, если это заканчивается ошибкой? На других системах ведь ему удается это сделать.

Выбирай либо asyncio либо не питон