Update: Test your available CPU resources in karaf

In the new version coming up with mhus-osgi-tools 1.3.3 the test automatically adjust thread amount. It increase the thread count up to a level no more CPU time can be consumed.

Here an example from my laptop using the autoInfo=true parameter to see how the algorithm is working:

karaf@root()> shityo stress autoInfo=true
Used cpu nanoseconds per second ...
CPU Time: 0 -> 0 = 0%, Threads: 1
Auto up
1: [2] 998M 997M = 1.996G
CPU Time: 0 -> 1996520601 = 100%, Threads: 2
Auto up
2: [3] 995M 999M 997M = 2.992G
CPU Time: 1996520601 -> 2992796194 = 33%, Threads: 3
Auto up
3: [4] 998M 998M 998M 998M = 3.994G
CPU Time: 2992796194 -> 3994464892 = 25%, Threads: 4
Auto up
4: [5] 998M 998M 998M 998M 998M = 4.992G
CPU Time: 3994464892 -> 4992347050 = 19%, Threads: 5
Auto up
5: [6] 998M 998M 999M 999M 997M 998M = 5.991G
CPU Time: 4992347050 -> 5991369437 = 16%, Threads: 6
Auto up
6: [7] 997M 994M 998M 997M 997M 997M 996M = 6.979G
CPU Time: 5991369437 -> 6979148659 = 14%, Threads: 7
Auto up
7: [8] 998M 1.001G 996M 998M 998M 997M 999M 998M = 7.988G
CPU Time: 6979148659 -> 7988812936 = 12%, Threads: 8
Auto up
8: [9] 709M 1000M 945M 999M 888M 998M 997M 715M 743M = 7.999G
CPU Time: 7988812936 -> 7999455368 = 0%, Threads: 9
9: [9] 745M 999M 999M 861M 998M 695M 998M 877M 823M = 7.999G
CPU Time: 7999455368 -> 7999942589 = 0%, Threads: 9
10: [9] 999M 1000M 998M 829M 832M 683M 998M 813M 846M = 8.001G
CPU Time: 7999942589 -> 8001307750 = 0%, Threads: 9
11: [9] 859M 878M 999M 999M 998M 739M 998M 767M 766M = 8.006G
CPU Time: 8001307750 -> 8006180402 = 0%, Threads: 9
12: [9] 942M 853M 997M 997M 996M 997M 789M 714M 694M = 7.983G
CPU Time: 8006180402 -> 7983121568 = 0%, Threads: 9
13: [9] 801M 997M 996M 942M 993M 753M 751M 744M 996M = 7.976G

^C

Kommentare

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

Sonatype Nexus fails with random "peer not authenticated" errors behind ingress

 After installing nexus3 server in a kubernetes environment in the first view everything looks good. Server is running an accessible from the world. Users and roles are defined and working. But already in the first hours of working with the repository there are problems. The trick was retry the failed activity and everything went ok. It turned out that heavy activities failed a lot of times and a lot of retries have to be done to finish the tasks. Annoying if a release deploy failed. You need to increase the version number every time. There were a few support in the internet for the problems most of the time handling SSL problems between maven and nexus. But it did not fix the problem. It looks like maven and the used http library wagon have got problems with pooled connections if using ingress (a test with a standalone installation did not show the problem)  - The 'deep' reason is not really clear for me, need to invest more time for it. The solution is to deny wagon to use p...
Mehr anzeigen

[mhus lib] Reorg in generation 7 nearly finished

 The generation 7 shows massive reorganisations and reimplementations. After renaming repository names (moved the 'cherry' prefix to 'mhus') the reorg is finished and the sources are ready for a more stable generation 8. Generation 8 will add new features to work with none OSGi services in cloud environments. Actual changes: cherry-reactiive -> mhus-reactive cherry-vault -> mhus-vault cherry-web -> mhus-web mhus-osgi-cluster -> mhus-cluster
Mehr anzeigen

[mhus lib] Implemented Bearer JWS tokens

 mhus now supports bearer tokens for authentication. I used the project jjwt to implement the tokens and added dependencies of the current version 0.11.2. The token is implemented to be used with apache shiro. A new service JwtProvider implements creation and reading of the tokens. The keys if not exists will be created and stored in the keychain. Private and public keys in separate key sources. In this way the public keys can be published to other nodes. A new interface BearerRealm must be used to mark realms with Bearer support. Using the interface a token can be created from the realm implementation. You should use the AccessUtil to create tokens. The authentication is already implemented in rest and micro calls. Via rest a node '/jwt_token' can be used to create a token - expires after one hour - and use it as authentication. To use jjwt with osgi I as forced to create a port project. First the 'feature' character of the bundles is not supported in the current felix...
Mehr anzeigen