Yngvie

В свое время использовали Siege-тест чтобы проверить разные возможные конфигурации

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

Если ваша программа не полагается на однопоточность, то нет смысла иметь количество процессов значительно превышающих количество ЦП/ядер. Идеальней будет использовать гибрид, количество процессов под количество ЦП, количество потоков… ну тут зависит больше от того, сколько памяти. У нас на разных проектах это обычно 5-25 потоков.

Хм, не знаю особенностей curl под Windows, поэтому точное число сказать не могу.

У Вас количество потоков прыгает между 10 и 90, попробуйте разные значения в этом диапазоне.

Ну и подбирать число потоков чтобы обеспечить работоспособность — это все таки не основное решение.
Добавьте обработчик ошибки который перезапустит задачу с текущим прокси.

Судя по тому, что ошибка возникает в строчке g = Grab() то ошибка возникает случайно, вне зависимости от каких либо параметров, так что зациклится оно не должно. Но на всякий случай можно ограничить количество перезапусков.

Рискну предположить, что проблема кроется в следующем:
curl.haxx.se/libcurl/features.html#thread
Хотя сам libcurl и заточен под многопоточность, он полагается на ряд фунций (например gethostby*) которые могут оказаться не thread-safe.

При большом количестве потоков возрастает шанс возникновения таких коллизий. Если это так, то можно отлавливать такие ошибки с помощью try..except и перезапускать парсер через какое-то время.

Еще неплохо было бы ограничить количество одновременно работающих потоков. У вас есть свой костыль для этого, но в питоне есть библиотека для работы с очередью задач:
docs.python.org/library/queue.html

Внизу есть простой пример.