Waarom heeft Rails threads nodig om te schalen?

[FooBarWidget]

Ik ben het Ruby on Rails web framework aan het onderzoeken, en ik heb van veel mensen gehoord dat het niet schaalt om het niet thread-safe is. De Ruby on Rails developers hebben recentelijk aangekondigd dat de volgende versie wel thread-safe zal zijn, maar ik heb de volgende vraag:

Waarom is thread-safety nodig voor een systeem om schaalbaar te zijn?

Ik ben afkomstig uit een C/C++/Java wereld en heb de nodige ervaring met multithreaded en multi-process programmeren. Ik snap de voor- en nadelen van zowel threads als processen, en het lijkt met bijzonder vreemd dat mensen beweren dat threads nodig zijn voor het schaalbaar maken van een systeem als Ruby on Rails.

Kan iemand het me uitleggen?

[Herko_ter_Horst]

A. Threads en thread-safety zijn twee verschillende dingen.
B. Als je de voor- en nadelen van threads en processen snapt, dan weet je dat threads minder memory overhead hebben dan processen, waarmee threads (gekoppeld aan thread-safety, dat bij losse processen een gegeven is) zorgen voor hogere schaalbaarheid.

[FooBarWidget]

A. Threads en thread-safety zijn twee verschillende dingen.

Dat snap ik, maar een gebrek aan thread-safety impliceert dat het systeem dan ook geen threads gebruikt.

B. Als je de voor- en nadelen van threads en processen snapt, dan weet je dat threads minder memory overhead hebben dan processen, waarmee threads (gekoppeld aan thread-safety, dat bij losse processen een gegeven is) zorgen voor hogere schaalbaarheid.

En copy-on-write semantieken dan? Het systeem kan zoveel mogelijk code en andere bronnen van tevoren laden, waarna het meerdere child processes aanmaakt met behulp van fork(). Al deze child processes zullen veel geheugen met elkaar delen dankzij copy-on-write optimalisaties in moderne virtual memory systemen. Dan hebben processen toch een vergelijkbare geheugenefficientie, met als bijkomend voordeel dat racing conditions en deadlocks en dergelijke niet mogelijk zijn, en dat als een enkel proces crasht de rest niet ook crasht?

EDIT: En als processen dankzij copy-on-write al geheugen met elkaar delen, wordt de CPU dan niet sneller een bottleneck dan geheugenverbruik? Als de CPU een bottleneck wordt dan helpen threads toch niet meer ten opzichte van processen?

[ Voor 10% gewijzigd door FooBarWidget op 17-08-2008 14:41 ]

[Alarmnummer]

Het probleem van Ruby mbt multithreading is dat het maar 1 core kan benutten. Ruby beheert zelf zijn 'threads' en is niet in staat om ruby threads over meerdere cpu cores te verdelen.

Wil je een 8 core systeem volledig benutten met ruby, zul je dus 8 ruby processen opstarten en assignen aan een specifieke core.

ps:
Zo was het in ieder geval in ruby. Ik hou me niet bezig met de nieuwste ontwikkelingen, dus het kan zijn dat ze intussen al wat zijn opgeschoten.

[ Voor 20% gewijzigd door Alarmnummer op 17-08-2008 15:47 ]

[MSalters]

Het antwoord op de eerste vraag is blijkbaar dat Ruby eigen Ruby-threads heeft. Als je N worker threads hebt, en 1 gedeelde thread (bv een loggiong thread) dan zijn al die threads in-process. Als Ruby dit over meerdere processen zou splutsen, dan moeten die twee Ruby processen via IPC informatie uitwisselen. Goedkope in-process synchronisatie is dan niet meer mogelijk.

Copy on Write heeft nog steeds toch gevolg dat je heap stukje bij beetje gekopieerd wordt, elke keer als er een paar bytes naar een page wordt geschreven.

En wat betreft het assignen van ruby processen aan cores; ik zou in zo'n geval adviseren om 10-20 processen aan te maken en het OS te laten schedulen. Elk Ruby proces gebruikt 1 OS thread, en het maakt dat process eigenlijk niet uit op welke core het runt.