Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7AA1A188C9 for ; Wed, 2 Mar 2016 07:39:56 +0000 (UTC) Received: (qmail 50312 invoked by uid 500); 2 Mar 2016 07:39:53 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 50267 invoked by uid 500); 2 Mar 2016 07:39:53 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 50257 invoked by uid 99); 2 Mar 2016 07:39:53 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Mar 2016 07:39:53 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 54295C06C5 for ; Wed, 2 Mar 2016 07:39:53 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.671 X-Spam-Level: * X-Spam-Status: No, score=1.671 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=2, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.329, SPF_PASS=-0.001] autolearn=disabled Received: from mx2-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id XJ4zNgpJr_EE for ; Wed, 2 Mar 2016 07:39:50 +0000 (UTC) Received: from mail.crowdstrike.com (dragosx.crowdstrike.com [208.42.231.60]) by mx2-lw-eu.apache.org (ASF Mail Server at mx2-lw-eu.apache.org) with ESMTPS id 142875F2C4 for ; Wed, 2 Mar 2016 07:39:48 +0000 (UTC) Received: from casmbox01.crowdstrike.sys (10.100.11.66) by ee01.crowdstrike.sys (10.100.0.12) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 1 Mar 2016 23:39:32 -0800 Received: from casmbox01.crowdstrike.sys (10.100.11.66) by casmbox01.crowdstrike.sys (10.100.11.66) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 1 Mar 2016 23:39:27 -0800 Received: from casmbox01.crowdstrike.sys ([fe80::9509:3711:75cb:b49f]) by casmbox01.crowdstrike.sys ([fe80::9509:3711:75cb:b49f%12]) with mapi id 15.00.0847.030; Tue, 1 Mar 2016 23:39:27 -0800 From: Jeff Jirsa To: "user@cassandra.apache.org" Subject: Re: Lot of GC on two nodes out of 7 Thread-Topic: Lot of GC on two nodes out of 7 Thread-Index: AQHRdFMIlpggJ1pbIUqZ+huDXgteiZ9FxKIA Date: Wed, 2 Mar 2016 07:39:26 +0000 Message-ID: <66234223-BECA-4668-9644-1CF9AFD307C3@crowdstrike.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.100.0.9] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3539720364_1714526237" MIME-Version: 1.0 --B_3539720364_1714526237 Content-type: multipart/alternative; boundary="B_3539720364_516797980" --B_3539720364_516797980 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Compaction falling behind will likely cause additional work on reads (more = sstables to merge), but I=E2=80=99d be surprised if it manifested in super long GC= . When you say twice as many sstables, how many is that?.=20 In cfstats, does anything stand out? Is max row size on those nodes larger = than on other nodes? What you don=E2=80=99t show in your JVM options is the new gen size =E2=80=93 if you do= have unusually large partitions on those two nodes (especially likely if yo= u have rf=3D2 =E2=80=93 if you have rf=3D3, then there=E2=80=99s probably a third node misbe= having you haven=E2=80=99t found yet), then raising new gen size can help handle t= he garbage created by reading large partitions without having to tolerate th= e promotion. Estimates for the amount of garbage vary, but it could be =E2=80=9Cgi= gabytes=E2=80=9D of garbage on a very wide partition (see https://issues.apache.or= g/jira/browse/CASSANDRA-9754 for work in progress to help mitigate that type= of pain). - Jeff=20 From: Anishek Agarwal Reply-To: "user@cassandra.apache.org" Date: Tuesday, March 1, 2016 at 11:12 PM To: "user@cassandra.apache.org" Subject: Lot of GC on two nodes out of 7 Hello,=20 we have a cassandra cluster of 7 nodes, all of them have the same JVM GC co= nfigurations, all our writes / reads use the TokenAware Policy wrapping a D= CAware policy. All nodes are part of same Datacenter. We are seeing that two nodes are having high GC collection times. Then most= ly seem to spend time in GC like about 300-600 ms. This also seems to result= in higher CPU utilisation on these machines. Other 5 nodes don't have this= problem. There is no additional repair activity going on the cluster, we are not sur= e why this is happening.=20 we checked cfhistograms on the two CF we have in the cluster and number of = reads seems to be almost same.=20 we also used cfstats to see the number of ssttables on each node and one of= the nodes with the above problem has twice the number of ssttables than oth= er nodes. This still doesnot explain why two nodes have high GC Overheads. o= ur GC config is as below: JVM_OPTS=3D"$JVM_OPTS -XX:+UseParNewGC" JVM_OPTS=3D"$JVM_OPTS -XX:+UseConcMarkSweepGC" JVM_OPTS=3D"$JVM_OPTS -XX:+CMSParallelRemarkEnabled" JVM_OPTS=3D"$JVM_OPTS -XX:SurvivorRatio=3D8" JVM_OPTS=3D"$JVM_OPTS -XX:MaxTenuringThreshold=3D50" JVM_OPTS=3D"$JVM_OPTS -XX:CMSInitiatingOccupancyFraction=3D70" JVM_OPTS=3D"$JVM_OPTS -XX:+UseCMSInitiatingOccupancyOnly" JVM_OPTS=3D"$JVM_OPTS -XX:+UseTLAB" JVM_OPTS=3D"$JVM_OPTS -XX:MaxPermSize=3D256m" JVM_OPTS=3D"$JVM_OPTS -XX:+AggressiveOpts" JVM_OPTS=3D"$JVM_OPTS -XX:+UseCompressedOops" JVM_OPTS=3D"$JVM_OPTS -XX:+CMSScavengeBeforeRemark" JVM_OPTS=3D"$JVM_OPTS -XX:ConcGCThreads=3D48" JVM_OPTS=3D"$JVM_OPTS -XX:ParallelGCThreads=3D48" JVM_OPTS=3D"$JVM_OPTS -XX:-ExplicitGCInvokesConcurrent" JVM_OPTS=3D"$JVM_OPTS -XX:+UnlockDiagnosticVMOptions" JVM_OPTS=3D"$JVM_OPTS -XX:+UseGCTaskAffinity" JVM_OPTS=3D"$JVM_OPTS -XX:+BindGCTaskThreadsToCPUs" # earlier value 131072 =3D 32768 * 4 JVM_OPTS=3D"$JVM_OPTS -XX:ParGCCardsPerStrideChunk=3D131072" JVM_OPTS=3D"$JVM_OPTS -XX:CMSScheduleRemarkEdenSizeThreshold=3D104857600" JVM_OPTS=3D"$JVM_OPTS -XX:CMSRescanMultiple=3D32768" JVM_OPTS=3D"$JVM_OPTS -XX:CMSConcMarkMultiple=3D32768" #new=20 JVM_OPTS=3D"$JVM_OPTS -XX:+CMSConcurrentMTEnabled" We are using cassandra 2.0.17. If anyone has any suggestion as to how what = else we can look for to understand why this is happening please do reply.=20 Thanks anishek --B_3539720364_516797980 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Compaction falling behin= d will likely cause additional work on reads (more sstables to merge), but I= ’d be surprised if it manifested in super long GC. When you say twice = as many sstables, how many is that?. 

In cfsta= ts, does anything stand out? Is max row size on those nodes larger than on o= ther nodes?

What you don’t show in your JVM o= ptions is the new gen size – if you do have unusually large partitions= on those two nodes (especially likely if you have rf=3D2 – if you have = rf=3D3, then there’s probably a third node misbehaving you haven’t= found yet), then raising new gen size can help handle the garbage created b= y reading large partitions without having to tolerate the promotion. Estimat= es for the amount of garbage vary, but it could be “gigabytes” o= f garbage on a very wide partition (see https://issues.apache.org/jira/browse/CASSAN= DRA-9754 for work in progress to help mitigate that type of pain).<= /div>

- Jeff 

From: Anishek Agarwal
Reply-To: "user@cassandra.apache.org"
Date: Tuesday, March 1, 2016 at 11:12 PM=
To: "user@cassandra.apache.org"
Subject: Lot of GC on two nodes out of 7

Hello,

we have a cassandra cluster of 7 nodes, all of them hav= e the same JVM GC configurations, all our writes /  reads use the Token= Aware Policy wrapping a DCAware policy. All nodes are part of same Datacente= r.

We are seeing that two nodes are having high GC = collection times. Then mostly seem to spend time in GC like about 300-600 ms= . This also seems to result in higher CPU utilisation on these machines. Oth= er  5 nodes don't have this problem.

There is = no additional repair activity going on the cluster, we are not sure why this= is happening. 
we checked cfhistograms on the two CF we have= in the cluster and number of reads seems to be almost same. 

we also used cfstats to see the number of ssttables on each = node and one of the nodes with the above problem has twice the number of sst= tables than other nodes. This still doesnot explain why two nodes have high = GC Overheads. our GC config is as below:

JVM_OPTS=3D"$JVM_OPTS -XX:+U= seParNewGC"

JVM_O= PTS=3D"$JVM_OPTS= -XX:+UseConcMarkSweepGC"

JVM_OPTS=3D"$J= VM_OPTS -XX:+CMSParallelRemarkEnabled"

JVM_OPTS=3D"$JVM_OPTS -XX:SurvivorRatio=3D8"

JVM_OPTS=3D"$JVM_OPTS -XX:MaxTenuringThreshold=3D50"

JVM_OPTS=3D"$JVM_OPTS -XX:CMSInitia= tingOccupancyFraction=3D70"

JVM_OPTS=3D"$J= VM_OPTS -XX:+UseCMSInitiatingOccupancyOnly"

JVM_OPTS=3D"$JVM_OPTS -XX:+UseTLAB"

= JVM_OPTS=3D"$JVM_OPTS -XX:MaxPermSize=3D256m"

JVM_OPTS=3D"= $JVM_OPTS -XX:+AggressiveOpts"

JVM_OPTS=3D"$JVM_OPTS -XX:+UseComp= ressedOops"

JVM_O= PTS=3D"$JVM_OPTS= -XX:+CMSScavengeBeforeRemark"

JVM_OPTS=3D"$JVM_OPTS -XX:ConcGCThreads=3D48= "

JVM_OPTS=3D"$JVM_OPTS -XX:ParallelGCThreads=3D48"

JVM_OPTS=3D"$JVM_OPTS -XX:-ExplicitGCInvokesConcurre= nt"

JVM_OPTS=3D"$JVM_OPTS -XX:+Un= lockDiagnosticVMOptions"

JVM_OPTS=3D"$JV= M_OPTS -XX:+UseGCTaskAffinity"

JVM_OPTS=3D"$JVM_OPTS -XX:+BindGCTaskThreadsToCPUs"

# earlier value 131072 =3D 32768 * 4

JVM_OPTS=3D"$JVM_OPTS -XX:ParGCCardsPerS= trideChunk=3D131072"

JVM_OPTS=3D"$JVM_OPTS= -XX:CMSScheduleRemarkEdenSizeThreshold=3D104857600"

JVM_OPTS=3D"$JVM_OPTS -XX:CMSRescanMultiple=3D32768"

JVM_OPTS=3D"$JVM_OPTS -XX:CMSConc= MarkMultiple=3D32768"

#new 

JVM_OPTS=3D"$JVM_OPTS -XX:+CMSConcurrentMTEnabled"


We are using cass= andra 2.0.17. If anyone has any suggestion as to how what else we can look f= or to understand why this is happening please do reply. 

=


Thanks
anishek
=

--B_3539720364_516797980-- --B_3539720364_1714526237 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIISYAYJKoZIhvcNAQcCoIISUTCCEk0CAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGggg8wMIIJlTCCB32gAwIBAgIKJGjoIQAAAAACYjANBgkqhkiG9w0BAQsFADBQMRMwEQYK CZImiZPyLGQBGRYDc3lzMRswGQYKCZImiZPyLGQBGRYLY3Jvd2RzdHJpa2UxHDAaBgNVBAMT E2Nyb3dkc3RyaWtlLVJPT1QtQ0EwHhcNMTUwNTE4MTcwNTU4WhcNMjMwNTE2MTcwNTU4WjCB nTETMBEGCgmSJomT8ixkARkWA3N5czEbMBkGCgmSJomT8ixkARkWC2Nyb3dkc3RyaWtlMRAw DgYDVQQLEwdDU1VzZXJzMRQwEgYDVQQLEwtFbmdpbmVlcmluZzEWMBQGA1UEAxMNSmVmZiBS LiBKaXJzYTEpMCcGCSqGSIb3DQEJARYaSmVmZi5KaXJzYUBjcm93ZHN0cmlrZS5jb20wggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDz/juPunY45nC7cetdyhafX455PB0ps4zm rZ/jR7NZfNWK11qq4CsWu9Agifcx7KlsmWSjn1EMopttM8axhSpgZOEKaiKSUI7NkihHKcpd ITBmx3XyhU2Dj5wBoftLbp54W+6AC5NYmsrlsqb1sw9CbRQRiALR+amfwzeZZOTKIpl2MYUJ 0qGkikpcl1wGQ1pXZYM4Bi3fa36IACgzgosONucxKMF9uOX8MUYaxdcU2wOpxvh3P4xw/CHO SQJsTaijjLDz+cZ7osYZmBlLdbHN2A55JxzMYlbNEb7xuOp7e3ooV8TV5I7LaD6ewPqu3B9Y nJnXoF+rNuf14D1tZWnT6BUBHIxNk1OTloOihowRaItAsSCUoY+KkRSFPWfwEOUEiynoSCUa gwyqIov+QP/KsGUf1J22yajmH9zexvkqoLohN56qhrAa+v3fZF0UyGk5V+EKeK4zxfu7tFwH Y9KJOPIl9jN5EBRiEpbe+j+6w8FO6+hOf3Pmr2R/IbQl9AP+saDqHGrCJrOUHZnNx+9YZ1pU TvUd/3qgQODgO28z/XqXmqqXefiwiqT9Ubmoiz7T//u069y3zquTD3PKoRnJLJuV4UIfnEdP HBIpClo9OQ2iz3CPGen+eTZprtaOlM926uweNTwDdsrjX3KiV2+bqLoLcAT2lzAFv1pSHp7O kQIDAQABo4IEITCCBB0wDgYDVR0PAQH/BAQDAgWgMD4GCSsGAQQBgjcVBwQxMC8GJysGAQQB gjcVCITk0CKH/Pdpg9mDAoHlqxCG+PJlgW6Gi7JugryReAIBZAIBFTCBlAYJKoZIhvcNAQkP BIGGMIGDMA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZI hvcNAwcwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBLTALBglghkgBZQMEARYwCwYJYIZIAWUD BAEZMAsGCWCGSAFlAwQBAjALBglghkgBZQMEAQUwHQYDVR0OBBYEFFeyMg1s94zEmeUrFyUT 1gtu/8mqMB8GA1UdIwQYMBaAFAnL7V4xGc1Nowmrlmwbj20X638YMIIBEwYDVR0fBIIBCjCC AQYwggECoIH/oIH8hoG6bGRhcDovLy9DTj1jcm93ZHN0cmlrZS1ST09ULUNBLENOPWRjMSxD Tj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln dXJhdGlvbixEQz1jcm93ZHN0cmlrZSxEQz1zeXM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz dD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hj1odHRwOi8vZGMxLmNy b3dkc3RyaWtlLnN5cy9DZXJ0RW5yb2xsL2Nyb3dkc3RyaWtlLVJPT1QtQ0EuY3JsMIIBKgYI KwYBBQUHAQEEggEcMIIBGDCBtgYIKwYBBQUHMAKGgalsZGFwOi8vL0NOPWNyb3dkc3RyaWtl LVJPT1QtQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9Y3Jvd2RzdHJpa2UsREM9c3lzP2NBQ2VydGlmaWNhdGU/ YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MF0GCCsGAQUFBzABhlFo dHRwOi8vZGMxLmNyb3dkc3RyaWtlLnN5cy9DZXJ0RW5yb2xsL2RjMS5jcm93ZHN0cmlrZS5z eXNfY3Jvd2RzdHJpa2UtUk9PVC1DQS5jcnQwKQYDVR0lBCIwIAYIKwYBBQUHAwIGCCsGAQUF BwMEBgorBgEEAYI3CgMEMDUGCSsGAQQBgjcVCgQoMCYwCgYIKwYBBQUHAwIwCgYIKwYBBQUH AwQwDAYKKwYBBAGCNwoDBDBNBgNVHREERjBEoCYGCisGAQQBgjcUAgOgGAwWamppcnNhQGNy b3dkc3RyaWtlLnN5c4EaSmVmZi5KaXJzYUBjcm93ZHN0cmlrZS5jb20wDQYJKoZIhvcNAQEL BQADggIBAIso1nTlfRcS3oWoWZ6gtjY0AH91GZpWft+O2kWxDUqzrmfmF+9swJXrk462v/m9 KAUxuch4mLC7j4tQ4FyNV64FZe+tU1fcNlg4wLIOjSoMykjx85sFbzh64YIpbpiX+8dqc/pF h6YcUU4PUgz7CZ0Q79J6bomV0EP94QUTN1AYLAYQ4xaPyLkO2DCtTiQ5Kef8jnNnrEYzZT62 OdljvhdGdV/VDMHAPr4yRPGgRou4Gf0cWsQNCav0RMEHPyJsgpXFCacLCCpvonXQoLMnClYT CVf7fWXdR+UtEpjssNMO2icJXNLarC7ngON7nzsqJKs40eKeAlKHlKXC620fCDbn6Icyodwd w32rkZDann2NAbrf8y2ArrXObRky1h/t8LDhkz/Yvvd5ndsKfQfciyCwIKBIcIgodR4MWobN qJzFIV5P/H/QGM8QLBdOwqEgwfqJjovgosxDXjb/aLbEuyCxgSTjZP6yv+90MFfs8ojV+0o2 Ir3q/H24u42nCD4gpGtb/+X16O1FV65QYlDPQyOomLnxBiuRji9BrazPvU4yIsHpJsZ5iTvG AvddQXQM4P7fNh+3esHBbvEwadPTOpUi/IfjQFsdDDaQw2QX6TjD5qT9vKimX2BpZmJIPvhi 9xXnmae7etpkBJ1Xrc8ysgpBRcZ0aKI4nyYmtGqNoov9MIIFkzCCA3ugAwIBAgIQHHI69IfK ebRHYrS5//qdkTANBgkqhkiG9w0BAQsFADBQMRMwEQYKCZImiZPyLGQBGRYDc3lzMRswGQYK CZImiZPyLGQBGRYLY3Jvd2RzdHJpa2UxHDAaBgNVBAMTE2Nyb3dkc3RyaWtlLVJPT1QtQ0Ew HhcNMTIwMzE4MDA1NjU4WhcNMzIwMzE4MDEwNjU0WjBQMRMwEQYKCZImiZPyLGQBGRYDc3lz MRswGQYKCZImiZPyLGQBGRYLY3Jvd2RzdHJpa2UxHDAaBgNVBAMTE2Nyb3dkc3RyaWtlLVJP T1QtQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCqrDGWg7do3ZjG04CVNLL6 voCUzmip/CbqyuCBAF3XNHjLsQnIhqQ+4sYkvozZVvR0CG3rvSe4YbSzOcHTsmK5bPiatuXB iUBO8rwHm5tzMUnjGk+XomeOGJzwemYsGIDJupLekvSrcm9dXX4H+GK97J42EkM8UAzsAGwn 7qpWo/bPrn7AM8kdua7DVbZbeJXjoid1NzFG4gjwdmtOtcwBx3DCs7io7C/R5Aep5APq4nmT gA7/whOpkxtThZCqiG8QprBRAktnmS2gMn3Kw1O0amPHtJr/O6FldgoK6Dkb9hKDftVFX9Te D7AlOVaZfltscXksnPxFBP0A6Bjw92hqR6QzRDqcWO+v1kswkd01jRrPPc410scWN7vX2QHv kCku8APiSIOGAvaLS/EtzcmjeJhCgkC6HVt5gjXXJBOMq9C2g82s8UiUnhj7D5/loaZffTyY 5y9mnZaxMbJavjmRV/vj0/Uuy+r1Z7WqIZ/0EhttmE+404YX4lAX/FtFjK0Ns5tpQgSxoIy2 ZUPTWmWsvwSiTud3Ek16IqxbPoQejuVhYnggjonpShvOeXAGcq+PMeQOIDoYl2fjlLTvUUvR LOvDse0F1nzo+6/OF+rr+h5iD2H4IAn0f/dasUIi77rU1mWMWWNTmRGP/7itZ2OhKakvxrtM sdbI4aj8AJPLnQIDAQABo2kwZzATBgkrBgEEAYI3FAIEBh4EAEMAQTAOBgNVHQ8BAf8EBAMC AYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUCcvtXjEZzU2jCauWbBuPbRfrfxgwEAYJ KwYBBAGCNxUBBAMCAQAwDQYJKoZIhvcNAQELBQADggIBADP4q4k1ZlMnD9FoC9nanmJsEli3 suYxE3VKFMNMF/g+YTv60ETh3k9op70DUPnowyphLgFAoI2ZmqVyaij5gYxUr9OGYHVUJecG oc6dYuQQUb6D6QDOJW+kUC/bSTJI5ICOGCQobSRuFPJKswbcq7QxA008+bq/S93zoH/afBgG VUMqGt/kiwvBra+ClRMu8m5RlpBmkLLy76zcznsWFaJNKnU4N0sWQLrrNh5jiaOT8MVmcoS5 OWfoy3Bp9zHEpT1zVrFvVDdl9+EIFwOAlfcg1jBIp037XxyxN526VUfowmJa86a+VnQVZH92 33y8qMjU2dGhqdXDFT8iHXbnFh3L6uxEjU6w2n90FXtuBaIvMlVKAOLqQrTkUC/FbTRVsCSh MzzpgEybnc4kcG0LdcEp4dh3NIArj5N37Tqh7pl2i7WBOfQ2ya4mz7f+G0bv1jImPgDK2I3F zd5f8uMvuCKbxMuDWdpaVRG8M+pwaVGV+b6nr5uoFno9QWk0VYz5035Yi/S0Bv2xT4jI/DR0 jT/A18fDQPGsp4JEk9/4XL0cndYi1mQSKnoKfNkKJGfv/dwLCNP3yEW9rHBbF5LSOe3apq/X NFH/7ZIkzRBkjngcXffbaClZdad8QALtQAqafYe7PnzNLyjbfpP4u6w2+9YW+yYx90SiSks/ oHPkRSBuMYIC9DCCAvACAQEwXjBQMRMwEQYKCZImiZPyLGQBGRYDc3lzMRswGQYKCZImiZPy LGQBGRYLY3Jvd2RzdHJpa2UxHDAaBgNVBAMTE2Nyb3dkc3RyaWtlLVJPT1QtQ0ECCiRo6CEA AAAAAmIwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgq58+X7m2TxbLV5vPd58s CsLBEU9Gxf1iwHH4ppB5etIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTYwMzAyMDczOTI0WjANBgkqhkiG9w0BAQEFAASCAgAXW1RO1gJfqslvVmFRUBY0 rua5iciulDTRW3lhqbsmhjOtOwZ25F18Pw2R32y2ffNxn3kkZzXbSRXbTdu5IPStDGK5o5lI AcWYQ3V/90y11uO3dA5E1AX+kDot2M1TBRQWzH1Kiw7e7I9vkLJqWZKkk4Ju2Tp5tcygCdRo wfb6CWlILp9l6KYlPrRqQirmAaE4vcDaOkW9NEc8wJHVDTeTtDb3ATvqsQ3ZfRX1BogzFqoD gfiDbBcmw1QR9I2wehT5U49eBZCXGOpvUjjn056vAVoMUlJCGwEYc6p5goo6wNr6kyAUzhST twGAv0Af5FtCLdMhD4qrJchsEFil3ySSvvFCgq1DSUls5JMBKchjbqYbsrTNFpcCwPxJnxVw UpI2zVWCVU7MWmUil43Y2p0h52T+yIyzCQMCiuuGrRQx+ymCvu6Q+VfqL8YECyEtcHJ1FLyC LwXe2jregMBoefTwX86h/8pPvKWmpVx41a8e0FH4ZBAltyqKe6ubyMhM8XOqH/B7V+Xq8AQx Y5tbPXORRipYuOwrd4H8HrQ/cxwwPFtMf0ZMTbVN1aHtWMSbBmo00nf67rVABSP1qp3zDn7I 6z5PO7wH4H+PJj/U+zcVAfiQaNusWnQUHjhGecZYCb0q2n2Np9+newYfxtaCq13kUl0/lJQH +cjr2LZUD9hTsQ== --B_3539720364_1714526237--