ধীরে ধীরে অ্যাপ্লিকেশন, ঘন ঘন JVM একক-সিপিইউ সেটআপস এবং জাভা 12+ এর সাথে স্থির থাকে

23

আমাদের একটি ক্লায়েন্ট অ্যাপ্লিকেশন রয়েছে (10+ বছরের বিকাশ সহ)। এর জেডিকে সম্প্রতি ওপেনজেডিকে 11 থেকে ওপেনজেডিকে 14 এ আপগ্রেড করা হয়েছে। সিঙ্গল-সিপিইউতে (হাইপার-থ্রেডিং অক্ষম) উইন্ডোজ 10 সেটআপগুলি (এবং কেবলমাত্র একটি উপলব্ধ সিপিইউ সহ ভার্চুয়ালবক্স মেশিনের ভিতরে) অ্যাপ্লিকেশনটি জাভা ১১ এর তুলনায় বেশ ধীরে ধীরে শুরু হয় Furthermore তদুপরি, এটি বেশিরভাগ সময় 100% সিপিইউ ব্যবহার করে। আমরা শুধুমাত্র একটি CPU- র প্রসেসর সম্বন্ধ স্থাপনের সঙ্গে সমস্যা পুনর্গঠন পারেনি ( c:\windows\system32\cmd.exe /C start /affinity 1 ...)।

অ্যাপ্লিকেশনটি শুরু করার এবং আমার ভার্চুয়ালবক্স মেশিনে ন্যূনতম ম্যানুয়াল ইন্টারঅ্যাকশন সহ একটি ক্যোয়ারী করার সাথে কিছু পরিমাপ:

  • ওপেনজেডিকে 11.0.2: 36 সেকেন্ড
  • ওপেনজেডিকে 13.0.2: ~ 1.5 মিনিট
  • ওপেনজেডিকে 13.0.2 সহ -XX:-UseBiasedLocking: 46 সেকেন্ড
  • ওপেনজেডিকে 13.0.2 এর সাথে -XX:-ThreadLocalHandshakes: 40 সেকেন্ড
  • ওপেনজেডিকে 14: 5-6 মিনিট
  • -XX:-UseBiasedLockingওপেনজেডিके 14 সহ : 3-3,5 মিনিট
  • ওপেনজেডকে 15 ইএ বিল্ড 20:, 4,5 মিনিট

শুধুমাত্র ব্যবহৃত জেডিকে (এবং উল্লিখিত বিকল্পগুলি) পরিবর্তন করা হয়েছে। ( -XX:-ThreadLocalHandshakesজাভা 14 এ উপলব্ধ নয়।)

আমরা জেডিকে 14 যা করে তা লগ করার চেষ্টা করেছি -Xlog:all=debug:file=app.txt:uptime,tid,level,tags:filecount=50।

প্রতিটি সেকেন্ডের জন্য লগ লাইনগুলি গণনা ওপেনজেডিকে 11.0.2 এর সাথে বেশ মসৃণ বলে মনে হচ্ছে:

$ cat jdk11-log/app* | grep "^\[" | cut -d. -f 1 | cut -d[ -f 2 | sort | uniq -c | sort -k 2 -n
  30710 0
  44012 1
  55461 2
  55974 3
  27182 4
  41292 5
  43796 6
  51889 7
  54170 8
  58850 9
  51422 10
  44378 11
  41405 12
  53589 13
  41696 14
  29526 15
   2350 16
  50228 17
  62623 18
  42684 19
  45045 20

অন্যদিকে, ওপেনজেডিকে 14 এর মনে হচ্ছে আকর্ষণীয় শান্ত সময়কাল রয়েছে:

$ cat jdk14-log/app* | grep "^\[" | cut -d. -f 1 | cut -d[ -f 2 | sort | uniq -c | sort -k 2 -n
   7726 0
   1715 5
  10744 6
   4341 11
  42792 12
  45979 13
  38783 14
  17253 21
  34747 22
   1025 28
   2079 33
   2398 39
   3016 44

সুতরাং, 1-4, 7-10 এবং 14-20 সেকেন্ডের মধ্যে কী ঘটছে?

...
[0.350s][7248][debug][class,resolve        ] jdk.internal.ref.CleanerFactory$1 java.lang.Thread CleanerFactory.java:45
[0.350s][7248][debug][class,resolve        ] jdk.internal.ref.CleanerImpl java.lang.Thread CleanerImpl.java:117
[0.350s][7248][info ][biasedlocking        ] Aligned thread 0x000000001727e010 to 0x000000001727e800
[0.350s][7248][info ][os,thread            ] Thread started (tid: 2944, attributes: stacksize: default, flags: CREATE_SUSPENDED STACK_SIZE_PARAM_IS)
[0.350s][6884][info ][os,thread            ] Thread is alive (tid: 6884).
[0.350s][6884][debug][os,thread            ] Thread 6884 stack dimensions: 0x00000000175b0000-0x00000000176b0000 (1024k).
[0.350s][6884][debug][os,thread            ] Thread 6884 stack guard pages activated: 0x00000000175b0000-0x00000000175b4000.
[0.350s][7248][debug][thread,smr           ] tid=7248: Threads::add: new ThreadsList=0x0000000017254500
[0.350s][7248][debug][thread,smr           ] tid=7248: ThreadsSMRSupport::free_list: threads=0x0000000017253d50 is freed.
[0.350s][2944][info ][os,thread            ] Thread is alive (tid: 2944).
[0.350s][2944][debug][os,thread            ] Thread 2944 stack dimensions: 0x00000000177b0000-0x00000000178b0000 (1024k).
[0.350s][2944][debug][os,thread            ] Thread 2944 stack guard pages activated: 0x00000000177b0000-0x00000000177b4000.
[0.351s][2944][debug][class,resolve        ] java.lang.Thread java.lang.Runnable Thread.java:832
[0.351s][2944][debug][class,resolve        ] jdk.internal.ref.CleanerImpl jdk.internal.misc.InnocuousThread CleanerImpl.java:135
[0.351s][2944][debug][class,resolve        ] jdk.internal.ref.CleanerImpl jdk.internal.ref.PhantomCleanable CleanerImpl.java:138
[0.351s][2944][info ][biasedlocking,handshake] JavaThread 0x000000001727e800 handshaking JavaThread 0x000000000286d800 to revoke object 0x00000000c0087f78
[0.351s][2944][debug][vmthread               ] Adding VM operation: HandshakeOneThread
[0.351s][6708][debug][vmthread               ] Evaluating non-safepoint VM operation: HandshakeOneThread
[0.351s][6708][debug][vmoperation            ] begin VM_Operation (0x00000000178af250): HandshakeOneThread, mode: no safepoint, requested by thread 0x000000001727e800

# no log until 5.723s

[5.723s][7248][info ][biasedlocking          ]   Revoked bias of currently-unlocked object
[5.723s][7248][debug][handshake,task         ] Operation: RevokeOneBias for thread 0x000000000286d800, is_vm_thread: false, completed in 94800 ns
[5.723s][7248][debug][class,resolve          ] java.util.zip.ZipFile$CleanableResource java.lang.ref.Cleaner ZipFile.java:715
[5.723s][7248][debug][class,resolve          ] java.lang.ref.Cleaner jdk.internal.ref.CleanerImpl$PhantomCleanableRef Cleaner.java:220
[5.723s][7248][debug][class,resolve          ] java.util.zip.ZipFile$CleanableResource java.util.WeakHashMap ZipFile.java:716
...

দ্বিতীয়টি কিছুটা বিরতি পরে:

...
[6.246s][7248][info ][class,load              ] java.awt.Graphics source: jrt:/java.desktop
[6.246s][7248][debug][class,load              ]  klass: 0x0000000100081a00 super: 0x0000000100001080 loader: [loader data: 0x0000000002882bd0 of 'bootstrap'] bytes: 5625 checksum: 0025818f
[6.246s][7248][debug][class,resolve           ] java.awt.Graphics java.lang.Object (super)
[6.246s][7248][info ][class,loader,constraints] updating constraint for name java/awt/Graphics, loader 'bootstrap', by setting class object
[6.246s][7248][debug][jit,compilation         ]   19       4       java.lang.Object::<init> (1 bytes)   made not entrant
[6.246s][7248][debug][vmthread                ] Adding VM operation: HandshakeAllThreads
[6.246s][6708][debug][vmthread                ] Evaluating non-safepoint VM operation: HandshakeAllThreads
[6.246s][6708][debug][vmoperation             ] begin VM_Operation (0x000000000203ddf8): HandshakeAllThreads, mode: no safepoint, requested by thread 0x000000000286d800
[6.246s][6708][debug][handshake,task          ] Operation: Deoptimize for thread 0x00000000026b0800, is_vm_thread: true, completed in 1400 ns
[6.246s][6708][debug][handshake,task          ] Operation: Deoptimize for thread 0x00000000026bb800, is_vm_thread: true, completed in 700 ns
[6.246s][6708][debug][handshake,task          ] Operation: Deoptimize for thread 0x00000000026ef800, is_vm_thread: true, completed in 100 ns
[6.246s][6708][debug][handshake,task          ] Operation: Deoptimize for thread 0x00000000026f0800, is_vm_thread: true, completed in 100 ns
[6.246s][6708][debug][handshake,task          ] Operation: Deoptimize for thread 0x00000000026f1800, is_vm_thread: true, completed in 100 ns
[6.246s][6708][debug][handshake,task          ] Operation: Deoptimize for thread 0x00000000026f4800, is_vm_thread: true, completed in 100 ns
[6.247s][6708][debug][handshake,task          ] Operation: Deoptimize for thread 0x0000000002768800, is_vm_thread: true, completed in 100 ns
[6.247s][6708][debug][handshake,task          ] Operation: Deoptimize for thread 0x000000000276e000, is_vm_thread: true, completed in 100 ns
[6.247s][6708][debug][handshake,task          ] Operation: Deoptimize for thread 0x0000000017268800, is_vm_thread: true, completed in 100 ns
[6.247s][6708][debug][handshake,task          ] Operation: Deoptimize for thread 0x000000001727e800, is_vm_thread: true, completed in 800 ns

# no log until 11.783s

[11.783s][6708][debug][handshake,task          ] Operation: Deoptimize for thread 0x000000000286d800, is_vm_thread: true, completed in 6300 ns
[11.783s][6708][info ][handshake               ] Handshake "Deoptimize", Targeted threads: 11, Executed by targeted threads: 0, Total completion time: 5536442500 ns
[11.783s][6708][debug][vmoperation             ] end VM_Operation (0x000000000203ddf8): HandshakeAllThreads, mode: no safepoint, requested by thread 0x000000000286d800
[11.783s][7248][debug][protectiondomain        ] Checking package access
[11.783s][7248][debug][protectiondomain        ] class loader: a 'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x00000000c0058628} protection domain: a 'java/security/ProtectionDomain'{0x00000000c058b948} loading: 'java/awt/Graphics'
[11.783s][7248][debug][protectiondomain        ] granted
[11.783s][7248][debug][class,resolve           ] sun.launcher.LauncherHelper java.awt.Graphics LauncherHelper.java:816 (reflection)
[11.783s][7248][debug][class,resolve           ] jdk.internal.reflect.Reflection [Ljava.lang.reflect.Method; Reflection.java:300
[11.783s][7248][debug][class,preorder          ] java.lang.PublicMethods$MethodList source: C:\Users\example\AppData\Local\example\stable\jdk\lib\modules
...

তারপরে তৃতীয়টি:

...
[14.578s][7248][debug][class,preorder          ] java.lang.InheritableThreadLocal source: C:\Users\example\AppData\Local\example\stable\jdk\lib\modules
[14.578s][7248][info ][class,load              ] java.lang.InheritableThreadLocal source: jrt:/java.base
[14.578s][7248][debug][class,load              ]  klass: 0x0000000100124740 super: 0x0000000100021a18 loader: [loader data: 0x0000000002882bd0 of 'bootstrap'] bytes: 1338 checksum: 8013ed55
[14.578s][7248][debug][class,resolve           ] java.lang.InheritableThreadLocal java.lang.ThreadLocal (super)
[14.578s][7248][debug][jit,compilation         ]  699       3       java.lang.ThreadLocal::get (38 bytes)   made not entrant
[14.578s][7248][debug][vmthread                ] Adding VM operation: HandshakeAllThreads
[14.578s][6708][debug][vmthread                ] Evaluating non-safepoint VM operation: HandshakeAllThreads
[14.578s][6708][debug][vmoperation             ] begin VM_Operation (0x000000000203d228): HandshakeAllThreads, mode: no safepoint, requested by thread 0x000000000286d800
[14.578s][6708][debug][handshake,task          ] Operation: Deoptimize for thread 0x00000000026b0800, is_vm_thread: true, completed in 1600 ns
[14.578s][6708][debug][handshake,task          ] Operation: Deoptimize for thread 0x00000000026bb800, is_vm_thread: true, completed in 900 ns
[14.578s][6708][debug][handshake,task          ] Operation: Deoptimize for thread 0x00000000026ef800, is_vm_thread: true, completed in 100 ns
[14.578s][6708][debug][handshake,task          ] Operation: Deoptimize for thread 0x00000000026f0800, is_vm_thread: true, completed in 100 ns
[14.578s][6708][debug][handshake,task          ] Operation: Deoptimize for thread 0x00000000026f1800, is_vm_thread: true, completed in 100 ns
[14.578s][6708][debug][handshake,task          ] Operation: Deoptimize for thread 0x00000000026f4800, is_vm_thread: true, completed in 0 ns
[14.578s][6708][debug][handshake,task          ] Operation: Deoptimize for thread 0x0000000002768800, is_vm_thread: true, completed in 0 ns
[14.578s][6708][debug][handshake,task          ] Operation: Deoptimize for thread 0x000000000276e000, is_vm_thread: true, completed in 0 ns
[14.578s][6708][debug][handshake,task          ] Operation: Deoptimize for thread 0x0000000017268800, is_vm_thread: true, completed in 0 ns
[14.579s][6708][debug][handshake,task          ] Operation: Deoptimize for thread 0x000000001727e800, is_vm_thread: true, completed in 900 ns

# no log until 21.455s

[21.455s][6708][debug][handshake,task          ] Operation: Deoptimize for thread 0x000000000286d800, is_vm_thread: true, completed in 12100 ns
[21.455s][6708][info ][handshake               ] Handshake "Deoptimize", Targeted threads: 11, Executed by targeted threads: 0, Total completion time: 6876829000 ns
[21.455s][6708][debug][vmoperation             ] end VM_Operation (0x000000000203d228): HandshakeAllThreads, mode: no safepoint, requested by thread 0x000000000286d800
[21.455s][7248][debug][class,resolve           ] sun.security.jca.Providers java.lang.InheritableThreadLocal Providers.java:39
[21.455s][7248][info ][class,init              ] 1251 Initializing 'java/lang/InheritableThreadLocal'(no method) (0x0000000100124740)
[21.455s][7248][debug][class,resolve           ] java.lang.InheritableThreadLocal java.lang.ThreadLocal InheritableThreadLocal.java:57
[21.456s][7248][debug][class,preorder          ] sun.security.jca.ProviderList source: C:\Users\example\AppData\Local\example\stable\jdk\lib\modules
[21.456s][7248][info ][class,load              ] sun.security.jca.ProviderList source: jrt:/java.base
[21.456s][7248][debug][class,load              ]  klass: 0x00000001001249a8 super: 0x0000000100001080 loader: [loader data: 0x0000000002882bd0 of 'bootstrap'] bytes: 11522 checksum: bdc239d2
[21.456s][7248][debug][class,resolve           ] sun.security.jca.ProviderList java.lang.Object (super)
...

নিম্নলিখিত দুটি লাইন আকর্ষণীয় বলে মনে হচ্ছে:

[11.783s][6708][info ][handshake               ] Handshake "Deoptimize", Targeted threads: 11, Executed by targeted threads: 0, Total completion time: 5536442500 ns
[21.455s][6708][info ][handshake               ] Handshake "Deoptimize", Targeted threads: 11, Executed by targeted threads: 0, Total completion time: 6876829000 ns

এই হ্যান্ডশেকগুলি 5.5 এবং 6.8 সেকেন্ডের মধ্যে লেগেছিল কি স্বাভাবিক?

আমি এই কমান্ডটি নিয়ে চলমান আপডেট 4j ডেমো অ্যাপ্লিকেশনটির সাথে একই ধীরগতি (এবং অনুরূপ লগগুলি) উপভোগ করেছি (যা আমাদের অ্যাপ্লিকেশনটির সাথে পুরোপুরি সম্পর্কিত নয়):

Z:\swing>\jdk-14\bin\java -Xlog:all=debug:file=app.txt:uptime,tid,level,tags:filecount=50 \
    -jar update4j-1.4.5.jar --remote http://docs.update4j.org/demo/setup.xml

সিঙ্গল-সিপিইউ উইন্ডোজ 10 সেটআপগুলিতে আমাদের অ্যাপটিকে আরও দ্রুততর করার জন্য আমার কী দেখার উচিত? আমরা কি আমাদের অ্যাপ্লিকেশনটিতে কিছু পরিবর্তন করে বা জেভিএম যুক্তি যুক্ত করে এটি ঠিক করতে পারি?

এটি কি জেডিকে বাগ, আমি কি এটি রিপোর্ট করব?

2020-04-25 আপডেট করুন:

আমি যতদূর দেখতে পাচ্ছি লগ ফাইলগুলিতেও জিসি লগ রয়েছে। এটি প্রথম জিসি লগগুলি:

$ cat app.txt.00 | grep "\[gc"
[0.016s][7248][debug][gc,heap          ] Minimum heap 8388608  Initial heap 60817408  Maximum heap 1073741824
[0.017s][7248][info ][gc,heap,coops    ] Heap address: 0x00000000c0000000, size: 1024 MB, Compressed Oops mode: 32-bit
[0.018s][7248][info ][gc               ] Using Serial
[22.863s][6708][info ][gc,start                ] GC(0) Pause Young (Allocation Failure)
[22.863s][6708][debug][gc,heap                 ] GC(0) Heap before GC invocations=0 (full 0): def new generation   total 17856K, used 15936K [0x00000000c0000000, 0x00000000c1350000, 0x00000000d5550000)
...

দুর্ভাগ্যক্রমে এটি তৃতীয় বিরতির পরে শুরু হওয়ার পরে এটি সম্পর্কিত বলে মনে হচ্ছে না।

2020-04-26 আপডেট করুন:

ওপেনজেডকে ১৪ এর সাথে অ্যাপ্লিকেশনটি আমার (একক-সিপিইউ) ভার্চুয়ালবক্স মেশিনে (একটি আই 7-6600U সিপিইউতে চলছে) 100% সিপিইউ ব্যবহার করে। ভার্চুয়াল মেশিনটিতে 3,5 জিবি র‌্যাম রয়েছে। টাস্ক ম্যানেজারের মতে 40% + নিখরচায় এবং ডিস্কের ক্রিয়াকলাপ 0% (আমি অনুমান করি এর অর্থ কোনও অদলবদল নয়)। ভার্চুয়াল মেশিনে অন্য একটি সিপিইউ যুক্ত করা (এবং শারীরিক মেশিনগুলির জন্য হাইপার-থ্রেডিং সক্ষম করা) অ্যাপ্লিকেশনটিকে দ্রুত পর্যাপ্ত করে তোলে। আমি কেবল ভাবছিলাম, জেডিকে উন্নয়নের সময় মাল্টিকোর / হাইপার-থ্রেডিং সিপিইউগুলিতে জেভিএমকে দ্রুততর করার জন্য (বিরল) একক-সিপিইউ মেশিনে পারফরম্যান্স হ্রাস করা ইচ্ছাকৃতভাবে বাণিজ্য বন্ধ ছিল?

java  hang  java-14 
— palacsint
সূত্র
3
না -Xlog:all=debugজিসি লগিং চালু করবেন? এটি কোনও বিরামের জন্য আমার প্রথম অনুমান হবে।
— কিচিক
আপনি কি কোনও প্রোফাইলারের সাথে চালানোর চেষ্টা করেছেন এবং ফলাফলগুলি তুলনা করেছেন? আমার মনে হয় এটাই স্বাভাবিক কাজ হবে।
— এক্সেল
1
উইন্ডোজ সিস্টেম বার্তাগুলিও পরীক্ষা করে দেখুন, জেডিডি 14 এর জন্য আলাদা বিল্ড চেষ্টা করুন else
— খান্না 111
1
@ ইয়ান.এফ: ওপেনজেডকে ১১ টি চিরকাল সমর্থন করা হবে না, এটি নতুন রিলিজ এবং বাগ প্রস্তুত করার সময় এসেছে। তদ্ব্যতীত, এটি একটি জেডিকে ত্রুটি বলে মনে হচ্ছে - এটি ঠিক করা হয়েছে বা নাও হতে পারে তবে অন্যকেও সহায়তা করতে পারে। যাইহোক, আমার কাছে এটি বেশিরভাগ কৌতূহল। অন্যদিকে আমি এখন আমাদের গ্রাহকদের আমাদের অ্যাপ্লিকেশনটির ন্যূনতম সিস্টেমের প্রয়োজনীয়তা হিসাবে কী বলব তা বলতে চাই।
— পালাকসিন্ট
1
@ খান্না ১১১১: হ্যাঁ, আমি এটি একটি উত্তর হিসাবে লিখেছি।
— প্যালাসিন্ট

উত্তর:

6

আমার অভিজ্ঞতা থেকে জেডিকে-র সাথে পারফরম্যান্সের সমস্যাগুলি বেশিরভাগ নীচের একটির সাথে সম্পর্কিত:

  • জেআইটি সংকলন
  • ভিএম কনফিগারেশন (গাদা আকার)
  • জিসি অ্যালগরিদম
  • জেভিএম / জেডিকে পরিবর্তনগুলি যা জানা ভাল চলমান অ্যাপ্লিকেশনগুলি ভেঙে দেয়
  • (ওহ, এবং আমি ক্লাস লোডিংয়ের কথা বলতে ভুলে গেছি ...)

আপনি যদি ওপেনজেডিকে 11 এর পরে কেবল ডিফল্ট জেভিএম কনফিগারেশন ব্যবহার করেন তবে জিসি, হিপ সাইজ ইত্যাদি স্থির মানগুলির জন্য আপনাকে আরও কিছু বিশিষ্ট বিকল্পগুলি সেট করা উচিত maybe

হয়তো কিছু গ্রাফিকাল বিশ্লেষণ সরঞ্জাম আপনার সমস্যাটি নিচে ট্র্যাক করতে সহায়তা করতে পারে। রিট্রেস, অ্যাপডিনামিক্স বা ফ্লাইটরেকর্ডার এবং এর মতো। এগুলি লগ ফাইল সরবরাহের চেয়ে একটি নির্দিষ্ট সময়ে হিপ, জিসি চক্র, র‌্যাম, থ্রেডস, সিপিইউ লোড ইত্যাদির সামগ্রিক অবস্থা সম্পর্কে আরও ওভারভিউ দেয়।

আমি কী সঠিকভাবে বুঝতে পারি যে আপনার অ্যাপ্লিকেশনটি চলমান প্রথম দ্বিতীয় (ওপেনজেডিকে 11 এর অধীনে) লগটিতে প্রায় 30710 টি লাইন লিখেছে? কেন এটি প্রথম "দ্বিতীয়" ওপেনজেডিকে 14 এর অধীনে প্রায় 7 কে লাইন লিখছে? এটি কেবলমাত্র আমার কাছে বিভিন্ন JVM- তে শুরু হওয়া কোনও অ্যাপ্লিকেশনের পক্ষে বিশাল পার্থক্যের মতো বলে মনে হচ্ছে ... লগের মধ্যে উচ্চমাত্রার ব্যতিক্রম স্ট্যাকট্রেসগুলি উদাহরণস্বরূপ নেই বলে আপনি কি নিশ্চিত?
অন্যান্য সংখ্যাগুলি কখনও কখনও আরও বেশি হয়, তাই সম্ভবত ধীরগতিগুলি ব্যতিক্রম লগিংয়ের সাথে সম্পর্কিত? বা এমনকি অদলবদল, র‌্যাম কম হলে?
আসলে আমি ভাবছি, যদি কোনও অ্যাপ্লিকেশন লগটিতে কিছু না লিখে থাকে তবে এটি সমস্যা ছাড়াই মসৃণভাবে চলার লক্ষণ (যদি এটি পুরোপুরি হিমায়িত না হয় তবে এই সময়ের মধ্যে)। 12-22 সেকেন্ড থেকে এখানে কী হচ্ছে (এখানে ওপেনজেডিকে 14 এর ক্ষেত্রে) যা আমাকে আরও চিন্তিত করবে ... লগইন করা লাইনগুলি ছাদ দিয়ে যাচ্ছে ... কেন ?
এরপর লগিং 1-2k সম্পর্কে লাইনের সব সময় কম মান যায় নিচে ... এর জন্য কারণ কী যে ?? (ভাল, সম্ভবত এটি জিসি দ্বিতীয় 22 এ লাথি মারছে এবং একটি তাবুল রস যা কিছু জিনিস সমাধান করে ...?)

"সিঙ্গল সিপিইউ" মেশিন সম্পর্কে আপনার অন্য বক্তব্য হতে পারে statement এটি কি "সিঙ্গল কোর" বোঝায় (আইড্ক, সম্ভবত আপনার সফ্টওয়্যারটি লেগ্যাসি হার্ডওয়ার বা কোনও কিছুর উপর নির্ভর করে)? এবং "একক সিপিইউ" ভিএমগুলি কি সেই যন্ত্রগুলিতে চলছে? তবে আমি ধরেই নিয়েছি, আমি এই অনুমানগুলি সম্পর্কে ভুল, যেহেতু আজকাল প্রায় সমস্ত সিপিইউ মাল্টিকোর হয় ... তবে আমি সম্ভবত একটি মাল্টিথ্রেডিং ইস্যু (অচলাবস্থা) সমস্যা নিয়ে তদন্ত করব।

— Antares
সূত্র
2
দয়া করে আপনার পোস্টগুলিতে স্বাক্ষর বা ট্যাগলাইন ব্যবহার করবেন না, পুনরাবৃত্তি "জিএল এবং এইচএফ" শব্দটি এবং আপনার পোস্টের বিষয়বস্তু থেকে একটি ব্যাঘাত এখানে বিবেচনা করা হয়। আরও তথ্যের জন্য meta.stackexchange.com/help/behaviour দেখুন ।
— মেগার
1
"আমি কী সঠিকভাবে বুঝতে পারি যে আপনার অ্যাপ্লিকেশনটি চলমান প্রথম দ্বিতীয় (ওপেনজেডিকে 11 এর অধীনে) লগটিতে প্রায় 30710 টি লাইন লিখেছে?" - হ্যাঁ আপনি ঠিক.
— প্যালাসিন্ট
1
"আপনি কি নিশ্চিত যে লগের জন্য উচ্চ পরিমাণে ব্যতিক্রম স্ট্যাকট্রেসগুলি ফেলে দেওয়া হয়নি?" - লগটি পরিষ্কার, আমি সেখানে কোনও অদ্ভুত কিছু পাইনি, অ্যাপ্লিকেশনটি সঠিকভাবে কাজ করে (বাদে এটি খুব খুব ধীরে ধীরে চলে)।
— প্যালাসিন্ট
1
জিসি 22 তম সেকেন্ডে লাথি মারছে এবং অ্যাপ্লিকেশন তার পরে ধীর থাকবে। আমি প্রশ্ন আপডেট করেছি। দয়া করে নোট করুন যে আপডেট4j ডেমো অ্যাপ্লিকেশনটিতেও একই সমস্যা রয়েছে। উত্তরের জন্য ধন্যবাদ!
— প্যালাসিন্ট
1
এক সেকেন্ডে 30 কে + লগ লাইনগুলি বেশ বিশাল ... আপনি কি সম্মতি দিচ্ছেন না? আমি সত্যিই অবাক হয়েছি যে এত অল্প সময়ে এই উচ্চ পরিমাণে লগ লাইনগুলি গ্রহণ করতে লগইন করার জন্য কী কার্যকর হতে পারে ... আপনি কি এই মোডে লগিং সম্পূর্ণরূপে বন্ধ এবং অ্যাপ্লিকেশনটিকে প্রোফাইল করার চেষ্টা করেছিলেন? (আমি জানতে আগ্রহী, কিন্তু হয়তো লগিং হিসাবে আপনি update4j আচরণ সঙ্গে পরোক্ষভাবে সত্যিই কোন প্রভাব আছে)
— Antares
5

যেহেতু এটি 100% সিপিইউ "বেশিরভাগ সময়" ব্যবহার করছে, এবং এটি জাভা 14 এর সাথে 10 গুণ বেশি (!) সময় নেয়, এর অর্থ আপনি জাভা 14 এ আপনার 90% সিপিইউ নষ্ট করছেন।

Apালু স্থানের বাইরে চলে যাওয়া এটি করতে পারে, আপনি যেমন পুরো সময়টাতে সিসিতে ব্যয় করেন তবে মনে হয় আপনি এটিকে বাতিল করে দিয়েছেন।

আমি লক্ষ্য করেছি যে আপনি পক্ষপাতযুক্ত লকিং বিকল্পটি টুইট করছেন, এবং এটি একটি উল্লেখযোগ্য পার্থক্য করে makes এটি আমাকে বলেছে যে সম্ভবত আপনার প্রোগ্রামটি একাধিক থ্রেডে প্রচুর সাম্প্রতিক কাজ করে। আপনার প্রোগ্রামের জাভা 14-এ প্রদর্শিত হবে যা জাভা 14-তে প্রদর্শিত হবে এটি সম্ভব হয়েছে, তবে জাভা 10-তে নয় another এটি আরও ব্যাখ্যা করতে পারে যে অন্য সিপিইউ যুক্ত করার কারণে এটি দ্বিগুণের চেয়ে দ্রুততর করে তোলে।

সংক্ষিপ্তসার বাগগুলি প্রায়শই কেবল তখন দেখা যায় যখন আপনি দুর্ভাগ্য হন এবং হ্যাশম্যাপ সংস্থার পরিবর্তনের মতো ট্রিগারটি আসলে কিছু হতে পারে etc.

প্রথমত, যদি এটি সম্ভব হয় তবে ঘুমের পরিবর্তে ব্যস্ত-অপেক্ষা করা এমন কোনও লুপ পরীক্ষা করুন।

তারপরে, স্যাম্পলিং মোডে একটি প্রোফাইলার চালান (jvisualvm করবে) এবং এমন পদ্ধতির সন্ধান করুন যা মোট সময়ের চেয়ে অনেক বড়% নিচ্ছে। যেহেতু আপনার পারফরম্যান্স 10 এর ফ্যাক্টর দ্বারা বন্ধ রয়েছে, তাই সেখানে কোনও সমস্যা সত্যিই বাইরে বেরিয়ে আসা উচিত।

— ম্যাট টিমারম্যানস
সূত্র
বিসিড লক করা অতীতে প্রয়োজনীয় ছিল তবে আজকাল এতটা নয়, এবং এটি ডিফল্টরূপে অক্ষম করার প্রস্তাব দেওয়া হয়েছিল এবং পরে অপসারণ করা হবে: ওপেনডেড.কাজা.नेट
— জোহানেসবি
2

এটি একটি আকর্ষণীয় ইস্যু এবং এটি সংকীর্ণ করার জন্য অনির্দিষ্টকালের প্রচেষ্টার প্রয়োজন হবে যেহেতু প্রচুর অনুমতি এবং সংমিশ্রণ রয়েছে যা চেষ্টা করে দেখার দরকার এবং ডেটা সংগ্রহ এবং সংঘবদ্ধ হতে পারে।

মনে হচ্ছে কিছু সময়ের জন্য এর কোনও সমাধান হয়নি। সম্ভবত এটি আরও বাড়ানোর প্রয়োজন হতে পারে।

সম্পাদনা 2: যেহেতু "থ্রেডলোক্যালহ্যান্ডশেকস" অবমূল্যায়ন করা হয়েছে এবং আমরা ধরে নিতে পারি যে লকিংটি বিতর্কিত হয়েছে, আশা করি এই দৃশ্যের গতি বাড়ানোর জন্য "ইউজবিজেডলকিং" না করে চেষ্টা করার পরামর্শ দিন।

তবে আরও তথ্য সংগ্রহ এবং সমস্যাটি বিচ্ছিন্ন করার চেষ্টা করার জন্য কিছু পরামর্শ রয়েছে are

  1. একাধিক কোর বরাদ্দ করুন [আমি দেখতে পাচ্ছি যে আপনি এটি ব্যবহার করে দেখেছেন এবং সমস্যাটি চলে গেছে। অন্যকে বাদ দিয়ে থ্রেড / গুলি কার্যকর করার বিষয়টি একটি সমস্যা বলে মনে হচ্ছে। নীচে 7 দেখুন)
  2. আরও গাদা বরাদ্দ করুন (সম্ভবত ভি 14 এর চাহিদা আগের জেডিএসের চেয়ে বেশি)
  3. উইন 10 ভিবিতে আরও মেমরি বরাদ্দ করুন।
  4. ওএস সিস্টেম বার্তাগুলি পরীক্ষা করুন (আপনার ক্ষেত্রে 10 জিতুন)
  5. এটি একটি অ-ভার্চুয়ালাইজড উইন 10 এ চালান।
  6. 14 এর 14 টি আলাদা বিল্ড চেষ্টা করুন
  7. প্রতিটি (বা প্রোফাইল) কয়েক বিরতিতে থ্রেড ডাম্প করুন। কোন থ্রেড একচেটিয়াভাবে চলছে তা বিশ্লেষণ করুন। সম্ভবত উপযুক্ত সময় ভাগ করে নেওয়ার জন্য একটি সেটিংস আছে। সম্ভবত উচ্চতর অগ্রাধিকারের থ্রেড চলছে। এই থ্রেডটি কী এবং এটি কী করছে? লিনাক্সে আপনি কোনও প্রক্রিয়ার সাথে যুক্ত লাইটওয়েট প্রক্রিয়াগুলি (থ্রেড) এবং রিয়েলটাইমের স্থিতিতে স্থির করতে পারেন। উইন 10 এর মতো কিছু?
  8. CPU 'র ব্যবহার? ১০০% বা তার চেয়ে কম? সিপিইউ বা মেম দ্বারা বাঁধা? পরিষেবা থ্রেডে 100% সিপিইউ? কোন পরিষেবা থ্রেড?
  9. আপনি কি স্পষ্টভাবে একটি জিসি অ্যালগো সেট করেছেন?

আমি ব্যক্তিগতভাবে সংস্করণগুলির মধ্যে সমস্যার মুখোমুখি হয়েছি যার জিসি, হিপ রিজাইজিং, ভার্চুয়ালাইজড পাত্রে সমস্যা এবং এর সাথে সম্পর্কিত।

এর কোনও সহজ উত্তর নেই, আমি মনে করি, বিশেষত যেহেতু এই প্রশ্নটি কিছু সময়ের জন্য রয়েছে। তবে আমরা সর্বোত্তম চেষ্টা করতে পারি এবং আমাদের কিছু বিচ্ছিন্ন পদক্ষেপের ফলাফল কী তা জানতে দিন।

সম্পাদনা 1: আপডেট হওয়া প্রশ্ন থেকে এটি মনে হয় যে কোনও জিসি বা অন্য কোনও পরিষেবা থ্রেডের সাথে একক কোর অ-ন্যায়সঙ্গতভাবে গ্রহণ করবে (থ্রেড-লোকাল হ্যান্ডশেকস)?

— Khanna111
সূত্র
জাভা এরগনোমিক্স থেকে ক্লায়েন্ট থেকে একটি সার্ভার ক্লাস ভিএম-তে বিভিন্ন জিসি এবং টায়ার্ড সংকলন সহ স্যুইচটি ট্রিগার করতে ব্যবহৃত অতিরিক্ত সিপিইউ কোর যুক্ত করা যদি এখনও এমনটি হয় তবে এটি পারফরম্যান্স এবং মেমরির ব্যবহারে হঠাৎ পার্থক্য ব্যাখ্যা করতে পারে, হ্যাঁ জেভিএম অভিনয় জটিল 😁
— জোহানেসবি
3
জাভা এরগনোমিক্স (ডিফল্ট সেটিংস) এখনও 1 সিপিইউ (যেমন: -XX: + UseSerialGC) বা 2 সিপিইউ'র (যেমন: G1GC, লুপস্ট্রিপমিনিংয়েরিটার = 1000, ... শর্টলুপ = 100) -র সাথে নিশ্চিত হওয়ার পরেও আলাদা মুদ্রণফ্ল্যাজফাইনাল যে আমি সমস্ত প্যারামিটারগুলিকে একই বা অনুরূপ চলমান আপডেট 4 জিতে টিকেট করেছি এখনও 2 সিপিইউ'র পরিবর্তে কেবলমাত্র একটি দিয়ে শুরু করতে খুব ধীর ছিল সেমিডি.এক্স / সি স্টার্ট / অ্যাফিনিটি 0x1 (তবে 0x3 দিয়ে অত্যন্ত দ্রুত - এইভাবে 2 সিপাস ব্যবহার করে (1 + 10 বাইনারি))। আমি নিশ্চিত করেছি যে আমরা কোনও এপসিলন জিসি ব্যবহার করে কোনও আবর্জনা সংগ্রহকারীকে দোষ দিতে পারি না যা কোনও জিসির ওভারহেড এড়াতে ডিজাইন করা হয়েছে। টাইয়ারড সংকলন সক্ষম করা আছে
— জোহানেসবি
আমি দেখি. এপসিলন জিসির সাথে দেখে মনে হচ্ছে এটি যেমন ধীর ছিল। এই ক্ষেত্রে, থ্রেডের স্ট্যাটাসগুলি এবং এটি কোথায় আটকে যায় তা মূল্যায়ন করার জন্য এটি একটি উপায় হতে পারে। জাভা ওয়ার্ল্ড এবং ওএস ওয়ার্ল্ড উভয়ই (আমার যদি মনে হয় লিনাক্সটি gcore ছিল)
— খান্না 111
2

টিএল; ডিআর : এটি ওপেনজেডিকে রিগ্রেশন।

আমি এটি ব্যতীত করিনি তবে আমি সাধারণ হ্যালো ওয়ার্ল্ডের সাথে বিষয়টি পুনরুত্পাদন করতে পারলাম:

public class Main {
    public static void main(String[] args) {
        System.out.println("Hello world");
    }
}

আমি এই দুটি ব্যাচের ফাইল ব্যবহার করেছি:

main-1cpu.bat, যা javaপ্রক্রিয়াটি কেবলমাত্র একটি সিপিইউতে সীমাবদ্ধ করে :

c:\windows\system32\cmd.exe /C start /affinity 1 \
    \jdk-14\bin\java \
    -Xlog:all=trace:file=app-1cpu.txt:uptime,tid,level,tags:filecount=50 \
    Main

main-full.bat, javaপ্রক্রিয়া দুটি সিপিইউ ব্যবহার করতে পারে:

c:\windows\system32\cmd.exe /C start /affinity FF \
    \jdk-14\bin\java \
    -Xlog:all=trace:file=app-full.txt:uptime,tid,level,tags:filecount=50 \
    Main

(পার্থক্যগুলি affinityলগ ফাইলের মূল্য এবং নাম। আমি এটি সহজ পঠনের জন্য আবৃত করেছি তবে মোড়ানো \সম্ভবত উইন্ডোজটিতে কাজ করে না))

ভার্চুয়ালবক্সে উইন্ডোজ 10 x64 এর কয়েকটি পরিমাপ (দুটি সিপিইউ সহ):

PS Z:\main> Measure-Command { .\main-1cpu.bat }

...    
TotalSeconds      : 7.0203455
...


PS Z:\main> Measure-Command { .\main-full.bat }

...
TotalSeconds      : 1.5751352
...


PS Z:\main> Measure-Command { .\main-full.bat }

...
TotalSeconds      : 1.5585384
...


PS Z:\main> Measure-Command { .\main-1cpu.bat }

...
TotalSeconds      : 23.6482685
...

উত্পাদিত ট্রেসলোগগুলিতে অনুরূপ বিরতি রয়েছে যা আপনি প্রশ্নটিতে দেখতে পারেন।

চলমান Maintracelogs ছাড়া দ্রুততর কিন্তু পার্থক্য এখনও একক CPU- র এবং দুই-CPU- র সংস্করণ মধ্যে দেখা যেতে পারে: ~ 4-7 সেকেন্ড বনাম ~ 400 MS।

আমি এই ফলাফলগুলি হটস্পট-ডেভেল ওপেনজেডকি মেল তালিকায় প্রেরণ করেছি এবং সেখানে ডিভাইসরা নিশ্চিত করেছে যে এটি এমন কিছু যা জেডিকে আরও ভালভাবে পরিচালনা করতে পারে । আপনি থ্রেডেও অনুমিত সমাধানগুলি খুঁজে পেতে পারেন । আশা করি এটি ওপেনজেডকে 15-এ স্থির করা হবে।

— palacsint
সূত্র
সাহায্য করার জন্য ধন্যবাদ!
— আনটারস
1

ধীর ডিস্কে লগিংয়ের বিষয়ে সতর্ক থাকুন, এটি আপনার অ্যাপ্লিকেশনটিকে ধীর করে দেবে:

https://engineering.linkedin.com/blog/2016/02/eliminating-large-jvm-gc-pauses-caused-by-background-io-traffic

তবে সিপিইউ এখনও ব্যস্ত থাকায় এবং থ্রেড-লোকাল হ্যান্ডশেকের জন্য আপনাকে সমস্ত থ্রেড নিরাপদ বিন্দুতে আসার অপেক্ষা করতে হবে না: https: // ওপেনজেডকে সমস্যার কারণ হতে পারে বলে মনে হচ্ছে না । java.net/jeps/312

এছাড়াও আপনার সমস্যার সাথে সরাসরি সম্পর্কিত নয় তবে সাধারণভাবে যদি আপনি প্রারম্ভকালের জন্য আপনার হার্ডওয়্যার থেকে আরও বেশি পারফরম্যান্স ছড়িয়ে দেওয়ার চেষ্টা করতে চান তবে অ্যাপসিডিএস (ক্লাস ডেটা শেয়ারিং) দেখুন:

https://blog.codefx.org/java/application-class-data-sharing/

— JohannesB
সূত্র
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.