Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Java archive cataloger performance in 0.82.x much slower than 0.81.0 #2200

Closed
driseley opened this issue Oct 18, 2024 · 6 comments
Closed

Java archive cataloger performance in 0.82.x much slower than 0.81.0 #2200

driseley opened this issue Oct 18, 2024 · 6 comments
Assignees
Labels
bug Something isn't working

Comments

@driseley
Copy link

What happened:
When upgrading grype from 0.81.0 to 0.82.1 (but also 0.82.0) the performance of scanning java heavy containers has decreased significantly

What you expected to happen:
The performance would be similar

How to reproduce it (as minimally and precisely as possible):

$ time ./grype-0810  docker:jenkins/jenkins:latest
...
A newer version of grype is available for download: 0.82.1 (installed version is 0.81.0)

real    0m8.504s
user    0m9.186s
sys     0m1.810s

Using -vv: [0007] INFO task completed elapsed=3.801204512s task=java-archive-cataloger

$ time ./grype-0821  docker:jenkins/jenkins:latest
...
real    0m28.791s
user    0m38.900s
sys     0m3.588s

Using -vv: [0027] INFO task completed elapsed=22.68268451s task=java-archive-cataloger

Anything else we need to know?:

Environment:

  • Output of grype version:
$ ./grype-0810 --version
grype 0.81.0
$ ./grype-0821 --version
grype 0.82.1
  • OS (e.g: cat /etc/os-release or similar):
$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.4 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.4 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy
@driseley driseley added the bug Something isn't working label Oct 18, 2024
@popey
Copy link
Contributor

popey commented Oct 18, 2024

Hi @driseley - thanks for the issue report and for providing an easily reproducible example.

I tried reproducing here on my system, running this twice, to ensure it was all downloaded before starting.

for f in grype-0810 grype-0820 grype-0821; do time ./$f jenkins/jenkins:latest -o json=$f.json; done

grype v0.81.0

 ✔ Vulnerability DB                [no update available]
 ✔ Parsed image sha256:f78b5b90f20c751402aee62cca2342ed20abb9af0d06e45cdc666918ad9f9a00
 ✔ Cataloged contents 62fe8db1f064ce5bfd13cf87d2dcc9083d129b083a43009dde3551393ca9f4fa
   ├── ✔ Packages                        [497 packages]
   ├── ✔ File digests                    [8,512 files]
   ├── ✔ File metadata                   [8,512 locations]
   └── ✔ Executables                     [931 executables]
 ✔ Scanned for vulnerabilities     [156 vulnerability matches]
   ├── by severity: 4 critical, 15 high, 22 medium, 8 low, 92 negligible (15 unknown)
   └── by status:   13 fixed, 143 not-fixed, 0 ignored

real	0m34.169s
user	0m16.733s
sys	0m1.634s

grype v0.82.0

 ✔ Parsed image sha256:f78b5b90f20c751402aee62cca2342ed20abb9af0d06e45cdc666918ad9f9a00
 ✔ Cataloged contents 62fe8db1f064ce5bfd13cf87d2dcc9083d129b083a43009dde3551393ca9f4fa
   ├── ✔ Packages                        [497 packages]
   ├── ✔ File digests                    [8,878 files]
   ├── ✔ File metadata                   [8,878 locations]
   └── ✔ Executables                     [931 executables]
 ✔ Scanned for vulnerabilities     [156 vulnerability matches]
   ├── by severity: 4 critical, 15 high, 22 medium, 8 low, 92 negligible (15 unknown)
   └── by status:   13 fixed, 143 not-fixed, 0 ignored
[0031]  WARN unable to discover java packages from opener: unable to process nested java archive (WEB-INF/lib/javax.inject-1.jar): /usr/share/jenkins/jenkins.war (sha256:9
[0059]  WARN unable to parse cpe attributes for elf binary package error=unable to parse Attributes string: failed to parse Attributes="": wfn: unsupported format ""

real	1m0.503s
user	0m58.470s
sys	0m3.019s

grype v0.82.1

 ✔ Parsed image sha256:f78b5b90f20c751402aee62cca2342ed20abb9af0d06e45cdc666918ad9f9a00
 ✔ Cataloged contents 62fe8db1f064ce5bfd13cf87d2dcc9083d129b083a43009dde3551393ca9f4fa
   ├── ✔ Packages                        [496 packages]
   ├── ✔ File digests                    [8,878 files]
   ├── ✔ File metadata                   [8,878 locations]
   └── ✔ Executables                     [931 executables]
 ✔ Scanned for vulnerabilities     [156 vulnerability matches]
   ├── by severity: 4 critical, 15 high, 22 medium, 8 low, 92 negligible (15 unknown)
   └── by status:   13 fixed, 143 not-fixed, 0 ignored
[0042]  WARN unable to discover java packages from opener: unable to process nested java archive (WEB-INF/lib/javax.inject-1.jar): /usr/share/jenkins/jenkins.war (sha256:9

real	1m2.205s
user	0m59.532s
sys	0m2.939s

I suspect this may be related to Grype v0.82.0 including Syft v1.14.0.

In Syft v1.13.0, we landed some changes which likely affected Java heavy containers.

@driseley
Copy link
Author

Thanks for coming back so quicky @popey .

Is this considered a bug, or just what we need to expect now?

For some of our internal images (which I can't share) the scan times have gone from 10secs to 2 mins, and we have pipelines that produce 10 java images - so the cumulative effect of this is quite pronounced?

@popey
Copy link
Contributor

popey commented Oct 18, 2024

Sorry that this is causing you pronounced issues. I appreciate this is not desirable.
The team is aware of the problem and its impact. They will take a look at the issue when they have a moment.
As a short-term workaround, can you revert to the older, faster release of Grype in the interim?

@driseley
Copy link
Author

Thanks for that, just wanted to know if it was going to be addressed in the future. For now we have reverted to the earlier version, which is fine for us for now. Thanks again for looking at this

@popey
Copy link
Contributor

popey commented Oct 18, 2024

Thanks for your patience. It's being looked at right now by the Best People. 😄
I'm not sure we'll crank a fixed release out, especially this late, on a Friday.
But I know there are solid theories. So if you're good for now, that's great to know. Have a great weekend.

@driseley
Copy link
Author

@wagoodman / @popey - many thanks for the fast fix, I can confirm performance for us has returned to the 0.81 levels

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Archived in project
Development

No branches or pull requests

3 participants