Recent

Author Topic: 5000 threads  (Read 4161 times)

tudi_x

  • Hero Member
  • *****
  • Posts: 532
5000 threads
« on: May 14, 2018, 09:07:17 am »
hi!
please advise if it would be an issue with Lazarus creating 5000 threads simultaneously (on ubuntu) for devops purposes aka checking services on the infrastructure.
i understand it is about 10 Gb RAM but RAM is cheap nowadays. (i do not know if i want to work with a thread pool at 5000 and maintain that amount of RAM occupied)
if the number is an issue, what would be the maximum that is stable.
thank you
Lazarus 2.0.2 64b on Debian LXDE 10

af0815

  • Hero Member
  • *****
  • Posts: 1289
Re: 5000 threads
« Reply #1 on: May 14, 2018, 09:41:34 am »
Threads are more CPU issue. Howw many Cores have the machine ? The CPU and the Sytemmust switch between the processes = Threads

I think 5000 Threads sounds like a bad design.

Andreas
regards
Andreas

Thaddy

  • Hero Member
  • *****
  • Posts: 14205
  • Probably until I exterminate Putin.
Re: 5000 threads
« Reply #2 on: May 14, 2018, 10:21:52 am »
Well there is a little more to it. In principle 5000 threads is not such a big problem (some webservers are in that ball park).
There are some issues that you need to take care of:
- Thread stack allocation: On Windows, the default is rather huge. Use the compiler switches to limit it.
- Context switching: try to avoid that with such a number of threads. Do NOT let the threads interact with each other: information sharing is a bad idea with so many threads.
- CPU cores and virtual cores: How many do you have? Devide 5000/cpu cores and using fibers per core or virtual core is usually more efficient.
Specialize a type, not a var.

Pascal

  • Hero Member
  • *****
  • Posts: 932
Re: 5000 threads
« Reply #3 on: May 14, 2018, 10:39:49 am »
Why not? As they are only checking services they are idle most of the time, arent't they?

You can also limit them to only run a specfied number simultaneously by using a semaphore.
So if you have a CPU with 8 threads you can limit them to 8 simultaneoiusly running.
laz trunk x64 - fpc trunk i386 (cross x64) - Windows 10 Pro x64 (21H2)

tudi_x

  • Hero Member
  • *****
  • Posts: 532
Re: 5000 threads
« Reply #4 on: May 14, 2018, 10:47:17 am »
from a requirements perspective i have to check that let us say (x > 100):
- x database instances have upgraded correctly by checking their version;
- x database instances are up every hour by running some SQL script;

so from a solution stand point what are my options?
Lazarus 2.0.2 64b on Debian LXDE 10

Pascal

  • Hero Member
  • *****
  • Posts: 932
Re: 5000 threads
« Reply #5 on: May 14, 2018, 11:47:54 am »
Build a list of "work to be done" with time stamp of execution.
Run 8 threads that pick up a "work to be done" with time stamps older than "now" and handle it and perhaps add a new "work to be done" with new time stamp for the next check (next hour).
laz trunk x64 - fpc trunk i386 (cross x64) - Windows 10 Pro x64 (21H2)

Thaddy

  • Hero Member
  • *****
  • Posts: 14205
  • Probably until I exterminate Putin.
Re: 5000 threads
« Reply #6 on: May 14, 2018, 11:48:41 am »
Well. That depends on the database software. In such a scenario and using Oracle -clustered - my above scenario should work pretty well on even very high demands... (read: been there, done that.. 8-) ). I would not attempt that with Sqlite or Firebird.... Possibly MySql, MariaDB and PostGress are good enough, though, to handle such a load.
Specialize a type, not a var.

Thaddy

  • Hero Member
  • *****
  • Posts: 14205
  • Probably until I exterminate Putin.
Re: 5000 threads
« Reply #7 on: May 14, 2018, 11:50:19 am »
Build a list of "work to be done" with time stamp of execution.
Run 8 threads that pick up a "work to be done" with time stamps older than "now" and handle it and perhaps add a new "work to be done" with new time stamp for the next check (next hour).
That is not relevant in a real-time scenario, which he explained and is referring to. You need a proper database back end to handle such load.
Specialize a type, not a var.

Pascal

  • Hero Member
  • *****
  • Posts: 932
Re: 5000 threads
« Reply #8 on: May 14, 2018, 12:45:50 pm »
Build a list of "work to be done" with time stamp of execution.
Run 8 threads that pick up a "work to be done" with time stamps older than "now" and handle it and perhaps add a new "work to be done" with new time stamp for the next check (next hour).
That is not relevant in a real-time scenario, which he explained and is referring to. You need a proper database back end to handle such load.
"every hour" doesn't sound like real-time scenario   :D
laz trunk x64 - fpc trunk i386 (cross x64) - Windows 10 Pro x64 (21H2)

Thaddy

  • Hero Member
  • *****
  • Posts: 14205
  • Probably until I exterminate Putin.
Re: 5000 threads
« Reply #9 on: May 14, 2018, 02:21:20 pm »
Indeed. But then you would not need 5000 threads but just two. That's how I read it. In the context of, say, a webserver 5000 threads is a valid proposition.
In the context of database operations a decent database should be able to maintain integrity. In that case the programming should be done database side.
Specialize a type, not a var.

Pascal

  • Hero Member
  • *****
  • Posts: 932
Re: 5000 threads
« Reply #10 on: May 14, 2018, 02:32:24 pm »
Indeed. But then you would not need 5000 threads but just two. That's how I read it. In the context of, say, a webserver 5000 threads is a valid proposition.
In the context of database operations a decent database should be able to maintain integrity. In that case the programming should be done database side.
Okay, right. In fact you'll never need 5000 threads for this monitoring tasks, even if you have to monitor 5000 db instances. Except they provide
some kind of notification for which the thread could wait. (I've done this for monitoring hundreds of directories on the network for changes)
laz trunk x64 - fpc trunk i386 (cross x64) - Windows 10 Pro x64 (21H2)

mdalacu

  • Full Member
  • ***
  • Posts: 233
    • dmSimpleApps
Re: 5000 threads
« Reply #11 on: May 14, 2018, 07:32:38 pm »
I also created a monitor software with ~100 working threads running through a job queue in loop.
I have a problem on Windows to create over 110 threads...on linux (fpc) and Delphi(windows) i do not have such issue.
I coudn't found a soution.

ASerge

  • Hero Member
  • *****
  • Posts: 2223
Re: 5000 threads
« Reply #12 on: May 14, 2018, 10:10:24 pm »
I have a problem on Windows to create over 110 threads...on linux (fpc) and Delphi(windows) i do not have such issue.
I coudn't found a soution.
Very strange. This simple example quite to itself works under windows and takes up around 140 MB of memory.
Code: Pascal  [Select][+][-]
  1. {$MODE OBJFPC}
  2. {$APPTYPE CONSOLE}
  3. program Project1;
  4.  
  5. uses Classes;
  6.  
  7. type
  8.   TSimpleThread = class(TThread)
  9.   private
  10.     FWaitEvent: PRTLEvent;
  11.     FCounter: PLongInt;
  12.   protected
  13.     procedure Execute; override;
  14.   public
  15.     constructor Create(AWaitEvent: PRTLEvent; ACounter: PLongInt);
  16.   end;
  17.  
  18. constructor TSimpleThread.Create(AWaitEvent: PRTLEvent; ACounter: PLongInt);
  19. begin
  20.   inherited Create(False);
  21.   FreeOnTerminate := True;
  22.   FWaitEvent := AWaitEvent;
  23.   FCounter := ACounter;
  24. end;
  25.  
  26. procedure TSimpleThread.Execute;
  27. begin
  28.   if Assigned(FCounter) then
  29.     InterLockedIncrement(FCounter^);
  30.   if Assigned(FWaitEvent) then
  31.   begin
  32.     RTLeventWaitFor(FWaitEvent);
  33.     RTLeventSetEvent(FWaitEvent);
  34.   end;
  35.   if Assigned(FCounter) then
  36.     InterLockedDecrement(FCounter^);
  37. end;
  38.  
  39. const
  40.   CMaxThreads = 5000;
  41. var
  42.   WaitEvent: PRTLEvent;
  43.   i: Integer;
  44.   Counter: LongInt = 0;
  45. begin
  46.   WaitEvent := RTLEventCreate;
  47.   for i := 1 to CMaxThreads do
  48.   begin
  49.     TSimpleThread.Create(WaitEvent, @Counter);
  50.     Write('.');
  51.   end;
  52.   Writeln;
  53.   Writeln(CMaxThreads, ' threads added. Press Enter to close this threads');
  54.   Readln;
  55.   RTLEventSetEvent(WaitEvent);
  56.   while Counter > 0 do
  57.     Writeln(Counter, ' treads left');
  58.   Writeln('All added threads are closed. Press Enter to exit');
  59.   RTLEventDestroy(WaitEvent);
  60.   Readln;
  61. end.

 

TinyPortal © 2005-2018