[Site Docusaurus Gladys] Build fehlt seit den letzten Airtable-Änderungen

pierre-gilles · 8. März 2021 um 05:41

Ich habe ein kleines Problem. Erinnerst du dich, du hattest das Airtable-Import-Skript auf Englisch entwickelt (das übrigens super funktioniert!), aber das Problem ist, dass ich seitdem, wenn ich versuche, die neuen Geräte, die auf Airtable hinzugefügt wurden, lokal zu importieren, Docusaurus nicht mehr starten kann ^^

Ich mache:

node scripts/load_integrations.js

Es werden 56 neue Dateien (Bilder, JSON, usw.) hinzugefügt, und alles scheint zu funktionieren:

Das Problem ist, dass, wenn ich die Seite neu starte, die Seite „Integrationen“ nicht mehr funktioniert (sie braucht stundenlang zum Laden – ohne Erfolg), und ein Build funktioniert nicht.

Ich bin mir nicht sicher, ob das unser Fehler ist, ich habe das Gefühl, dass es von Docusaurus kommen könnte, das Probleme hat, wenn man ihm zu viele Bilder zum Verarbeiten gibt, und dass wir eine „Grenze“ überschritten haben.

Oder aber, es ist unser Fehler und es gibt ein einfaches Problem (wie ein fehlendes Bild, so etwas in der Art…), aber ich würde mich wundern, das würde einen klaren Fehler verursachen.

pierre-gilles · 8. März 2021 um 06:59

Hey @cicoub13, ich habe das Problem alleine gelöst

Edit: Nein, das Problem ist nicht gelöst. Endloser Build auf Github Actions.

Es gab zwei Probleme:

Es gab einen „en“-Ordner, der in der Integrationsansicht hardcodiert war, und daher wurden einige Bilder nicht gefunden (Get new devices from AirTable by Pierre-Gilles · Pull Request #57 · GladysAssistant/v4-website · GitHub)
Einige Bilder, die im Repo, aber nicht in Airtable waren, befanden sich im „en“-Ordner, aber nicht im „fr“-Ordner, wodurch der „fr“-Build kaputt ging

Durch die Behebung beider Probleme scheine ich die Website anzeigen zu können und die Builds funktionieren!

pierre-gilles · 8. März 2021 um 07:11

Ich habe zu früh gesprochen!

Offensichtlich ist es immer noch kaputt, der Build läuft endlos auf Github Actions…

siehe

https://github.com/GladysAssistant/v4-website/runs/2054279591?check_suite_focus=true

pierre-gilles · 8. März 2021 um 07:18

Der Fehler bei Github Actions:

2021-03-08T06:58:45.3525026Z ##[group]Run ./build.sh
2021-03-08T06:58:45.3525558Z [36;1m./build.sh[0m
2021-03-08T06:58:45.3571277Z shell: /bin/bash -e {0}
2021-03-08T06:58:45.3571855Z ##[endgroup]
2021-03-08T06:58:46.6430726Z 
2021-03-08T06:58:46.6433031Z > gladys-4-docusaurus@1.0.0 postinstall /home/runner/work/v4-website/v4-website
2021-03-08T06:58:46.6434443Z > cd en && npm install && cd ../fr && npm install
2021-03-08T06:58:46.6435062Z 
2021-03-08T06:58:56.4145957Z npm WARN @docusaurus/plugin-content-blog@2.0.0-alpha.58 requires a peer of @docusaurus/core@^2.0.0 but none is installed. You must install peer dependencies yourself.
2021-03-08T06:58:56.4235669Z npm WARN @docusaurus/plugin-content-docs@2.0.0-alpha.58 requires a peer of @docusaurus/core@^2.0.0 but none is installed. You must install peer dependencies yourself.
2021-03-08T06:58:56.4313076Z npm WARN @docusaurus/plugin-content-pages@2.0.0-alpha.58 requires a peer of @docusaurus/core@^2.0.0 but none is installed. You must install peer dependencies yourself.
2021-03-08T06:58:56.4391487Z npm WARN @docusaurus/plugin-debug@2.0.0-alpha.58 requires a peer of @docusaurus/core@^2.0.0 but none is installed. You must install peer dependencies yourself.
2021-03-08T06:58:56.4478723Z npm WARN @docusaurus/plugin-google-analytics@2.0.0-alpha.37 requires a peer of @docusaurus/core@^2.0.0 but none is installed. You must install peer dependencies yourself.
2021-03-08T06:58:56.4572167Z npm WARN @docusaurus/plugin-google-gtag@2.0.0-alpha.58 requires a peer of @docusaurus/core@^2.0.0 but none is installed. You must install peer dependencies yourself.
2021-03-08T06:58:56.4658446Z npm WARN @docusaurus/plugin-ideal-image@2.0.0-alpha.39 requires a peer of @docusaurus/core@^2.0.0 but none is installed. You must install peer dependencies yourself.
2021-03-08T06:58:56.4747398Z npm WARN @docusaurus/plugin-sitemap@2.0.0-alpha.58 requires a peer of @docusaurus/core@^2.0.0 but none is installed. You must install peer dependencies yourself.
2021-03-08T06:58:56.4829614Z npm WARN @docusaurus/preset-classic@2.0.0-alpha.58 requires a peer of @docusaurus/core@^2.0.0 but none is installed. You must install peer dependencies yourself.
2021-03-08T06:58:56.4909901Z npm WARN @docusaurus/plugin-google-analytics@2.0.0-alpha.58 requires a peer of @docusaurus/core@^2.0.0 but none is installed. You must install peer dependencies yourself.
2021-03-08T06:58:56.4991920Z npm WARN @docusaurus/plugin-sitemap@2.0.0-alpha.58 requires a peer of @docusaurus/core@^2.0.0 but none is installed. You must install peer dependencies yourself.
2021-03-08T06:58:56.5076229Z npm WARN @docusaurus/theme-classic@2.0.0-alpha.58 requires a peer of @docusaurus/core@^2.0.0 but none is installed. You must install peer dependencies yourself.
2021-03-08T06:58:56.5151365Z npm WARN @docusaurus/theme-search-algolia@2.0.0-alpha.58 requires a peer of @docusaurus/core@^2.0.0 but none is installed. You must install peer dependencies yourself.
2021-03-08T06:58:56.5249191Z npm WARN @endiliey/lqip-loader@3.0.2 requires a peer of file-loader@* but none is installed. You must install peer dependencies yourself.
2021-03-08T06:58:56.5371780Z npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.1.3 (node_modules/fsevents):
2021-03-08T06:58:56.5376096Z npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.1.3: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
2021-03-08T06:58:56.5470535Z npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.13 (node_modules/watchpack-chokidar2/node_modules/fsevents):
2021-03-08T06:58:56.5474196Z npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.13: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
2021-03-08T06:58:56.5610043Z npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.13 (node_modules/webpack-dev-server/node_modules/fsevents):
2021-03-08T06:58:56.5612373Z npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.13: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
2021-03-08T06:58:56.5613788Z 
2021-03-08T06:58:56.5639583Z audited 1716 packages in 9.485s
2021-03-08T06:58:57.5825084Z 
2021-03-08T06:58:57.5826242Z 124 packages are looking for funding
2021-03-08T06:58:57.5826956Z   run `npm fund` for details
2021-03-08T06:58:57.5827422Z 
2021-03-08T06:58:57.5838635Z found 933 vulnerabilities (927 low, 1 moderate, 5 high)
2021-03-08T06:58:57.5839828Z   run `npm audit fix` to fix them, or `npm audit` for details
2021-03-08T06:59:07.9415998Z npm WARN @docusaurus/plugin-content-blog@2.0.0-alpha.58 requires a peer of @docusaurus/core@^2.0.0 but none is installed. You must install peer dependencies yourself.
2021-03-08T06:59:07.9500549Z npm WARN @docusaurus/plugin-content-docs@2.0.0-alpha.58 requires a peer of @docusaurus/core@^2.0.0 but none is installed. You must install peer dependencies yourself.
2021-03-08T06:59:07.9581055Z npm WARN @docusaurus/plugin-content-pages@2.0.0-alpha.58 requires a peer of @docusaurus/core@^2.0.0 but none is installed. You must install peer dependencies yourself.
2021-03-08T06:59:07.9656513Z npm WARN @docusaurus/plugin-debug@2.0.0-alpha.58 requires a peer of @docusaurus/core@^2.0.0 but none is installed. You must install peer dependencies yourself.
2021-03-08T06:59:07.9729041Z npm WARN @docusaurus/plugin-google-analytics@2.0.0-alpha.37 requires a peer of @docusaurus/core@^2.0.0 but none is installed. You must install peer dependencies yourself.
2021-03-08T06:59.07.9812613Z npm WARN @docusaurus/plugin-google-gtag@2.0.0-alpha.58 requires a peer of @docusaurus/core@^2.0.0 but none is installed. You must install peer dependencies yourself.
2021-03-08T06:59:07.9891795Z npm WARN @docusaurus/plugin-ideal-image@2.0.0-alpha.39 requires a peer of @docusaurus/core@^2.0.0 but none is installed. You must install peer dependencies yourself.
2021-03-08T06:59:07.9969374Z npm WARN @docusaurus/plugin-sitemap@2.0.0-alpha.58 requires a peer of @docusaurus/core@^2.0.0 but none is installed. You must install peer dependencies yourself.
2021-03-08T06:59:08.0048846Z npm WARN @docusaurus/preset-classic@2.0.0-alpha.58 requires a peer of @docusaurus/core@^2.0.0 but none is installed. You must install peer dependencies yourself.
2021-03-08T06:59:08.0158446Z npm WARN @docusaurus/plugin-google-analytics@2.0.0-alpha.58 requires a peer of @docusaurus/core@^2.0.0 but none is installed. You must install peer dependencies yourself.
2021-03-08T06:59:08.0253014Z npm WARN @docusaurus/plugin-sitemap@2.0.0-alpha.58 requires a peer of @docusaurus/core@^2.0.0 but none is installed. You must install peer dependencies yourself.
2021-03-08T06:59:08.0331413Z npm WARN @docusaurus/theme-classic@2.0.0-alpha.58 requires a peer of @docusaurus/core@^2.0.0 but none is installed. You must install peer dependencies yourself.
2021-03-08T06:59:08.0408575Z npm WARN @docusaurus/theme-search-algolia@2.0.0-alpha.58 requires a peer of @docusaurus/core@^2.0.0 but none is installed. You must install peer dependencies yourself.
2021-03-08T06:59:08.0484329Z npm WARN @endiliey/lqip-loader@3.0.2 requires a peer of file-loader@* but none is installed. You must install peer dependencies yourself..
2021-03-08T06:59:08.0617168Z npm WARN optional ÜBERSPRINGEN VON OPTIONALER ABHÄNGIGKEIT: fsevents@2.1.3 (node_modules/fsevents):
2021-03-08T06:59:08.0618792Z npm WARN notsup ÜBERSPRINGEN VON OPTIONALER ABHÄNGIGKEIT: Nicht unterstützte Plattform für fsevents@2.1.3: gewünscht {"os":"darwin","arch":"any"} (aktuell: {"os":"linux","arch":"x64"})
2021-03-08T06:59:08.0708620Z npm WARN optional ÜBERSPRINGEN VON OPTIONALER ABHÄNGIGKEIT: fsevents@1.2.13 (node_modules/watchpack-chokidar2/node_modules/fsevents):
2021-03-08T06:59:08.0710347Z npm WARN notsup ÜBERSPRINGEN VON OPTIONALER ABHÄNGIGKEIT: Nicht unterstützte Plattform für fsevents@1.2.13: gewünscht {"os":"darwin","arch":"any"} (aktuell: {"os":"linux","arch":"x64"})
2021-03-08T06:59:08.0796188Z npm WARN optional ÜBERSPRINGEN VON OPTIONALER ABHÄNGIGKEIT: fsevents@1.2.13 (node_modules/webpack-dev-server/node_modules/fsevents):
2021-03-08T06:59:08.0798586Z npm WARN notsup ÜBERSPRINGEN VON OPTIONALER ABHÄNGIGKEIT: Nicht unterstützte Plattform für fsevents@1.2.13: gewünscht {"os":"darwin","arch":"any"} (aktuell: {"os":"linux","arch":"x64"})
2021-03-08T06:59:08.0799947Z 
2021-03-08T06:59:08.0832702Z 1716 Pakete in 9,472s geprüft
2021-03-08T06:59:09.1281464Z 
2021-03-08T06:59:09.1282943Z 124 Pakete suchen nach Finanzierung
2021-03-08T06:59:09.1284002Z   Führe `npm fund` für Details aus
2021-03-08T06:59:09.1284496Z 
2021-03-08T06:59:09.1289505Z 933 Schwachstellen gefunden (927 geringfügig, 1 moderat, 5 schwerwiegend)
2021-03-08T06:59:09.1290616Z   Führe `npm audit fix` aus, um sie zu beheben, oder `npm audit` für Details
2021-03-08T06:59:09.3685909Z 152 Pakete in 23,574s geprüft
2021-03-08T06:59:09.4326662Z 
2021-03-08T06:59:09.4327502Z 4 Pakete suchen nach Finanzierung
2021-03-08T06:59:09.4328030Z   Führe `npm fund` für Details aus
2021-03-08T06:59:09.4328327Z 
2021-03-08T06:59:09.4337051Z 1 schwerwiegende Schwachstelle gefunden
2021-03-08T06:59:09.4337897Z   Führe `npm audit fix` aus, um sie zu beheben, oder `npm audit` für Details
2021-03-08T06:59:09.9692267Z 
2021-03-08T06:59:09.9694460Z > my-website@0.0.0 build /home/runner/work/v4-website/v4-website/en
2021-03-08T06:59:09.9695570Z > docusaurus build
2021-03-08T06:59:09.9696141Z 
2021-03-08T06:59:11.3906591Z Erstellen eines optimierten Produktionsbuilds...
2021-03-08T06:59:11.8991700Z [info] [webpackbar] Client kompilieren
2021-03-08T06:59:11.9217023Z [info] [webpackbar] Server kompilieren
2021-03-08T07:13:44.4220901Z 
2021-03-08T07:13:44.4222642Z <--- Letzte paar GCs --->
2021-03-08T07:13:44.4223196Z 
2021-03-08T07:13:44.4224703Z [3229:0x4ce0f70]   872349 ms: Mark-sweep 1990,9 (2067,7) -> 1973,9 (2067,0) MB, 2169,4 / 0,2 ms  (durchschnittlicher mu = 0,244, aktueller mu = 0,256) Speicherbereinigung könnte fehlschlagen
2021-03-08T07:13:44.4227033Z [3229:0x4ce0f70]   872444 ms: Scavenge 1989,0 (2067,0) -> 1976,3 (2067,0) MB, 12,7 / 0,0 ms  (durchschnittlicher mu = 0,244, aktueller mu = 0,256) Speicherbereinigung könnte fehlschlagen 
2021-03-08T07:13:44.4229622Z [3229:0x4ce0f70]   872547 ms: Scavenge 1990,1 (2067,0) -> 1978,9 (2067,0) MB, 22,7 / 0,0 ms  (durchschnittlicher mu = 0,244, aktueller mu = 0,256) Speicherbereinigung könnte fehlschlagen 
2021-03-08T07:13:44.4230693Z 
2021-03-08T07:13:44.4232342Z 
2021-03-08T07:13:44.4233332Z <--- JS Stacktrace --->
2021-03-08T07:13:44.4233856Z 
2021-03-08T07:13:44.4234496Z ==== JS Stacktrace =========================================
2021-03-08T07:13:44.4234969Z 
2021-03-08T07:13:44.4235555Z     0: ExitFrame [pc: 0x140a7f9]
2021-03-08T07:13:44.4236321Z Sicherheitskontext: 0x32e4e90008d1 <JSObject>
2021-03-08T07:13:44.4238348Z     1: /* anonym */ [0x26edba36dd71] [/home/runner/work/v4-website/v4-website/en/node_modules/acorn/dist/acorn.js:~808] [pc=0x12746eec88ce](this=0x22c8d4304271 <Parser map = 0x1a1ae9a7ec39>,0x0a9642f8b859 <String[#3]: for>,0x2ee3d23404b1 <undefined>,0x2ee3d23404b1 <undefined>)
2021-03-08T07:13:44.4240491Z     2: /* anonym */ [0x26edba36e1f1] [/home/runner/work/v4-website/v4-website/en/...
2021-03-08T07:13:44.4241521Z 
2021-03-08T07:13:44.4244430Z FATALER FEHLER: Ineffektive Mark-Compacts in der Nähe der Heap-Grenze Speicherzuweisung fehlgeschlagen - JavaScript-Heap aus Speicher
2021-03-08T07:13:44.4931042Z  1: 0xa18150 node::Abort() [node]
2021-03-08T07:13:44.4931907Z  2: 0xa1855c node::OnFatalError(char const*, char const*) [node]
2021-03-08T07:13:44.4932979Z  3: 0xb9705e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
2021-03-08T07:13:44.4934117Z  4: 0xb973d9 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
2021-03-08T07:13:44.4935284Z  5: 0xd54655  [node]
2021-03-08T07:13:44.4936094Z  6: 0xd54ce6 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [node]
2021-03-08T07:13:44.4937444Z  7: 0xd615a5 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [node]
2021-03-08T07:13:44.4939291Z  8: 0xd62455 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
2021-03-08T07:13:44.4941620Z  9: 0xd64f0c v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
2021-03-08T07:13:44.4944822Z 10: 0xd2b92b v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [node]
2021-03-08T07:13:44.4948355Z 11: 0x106defe v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [node]
2021-03-08T07:13:44.4958799Z 12: 0x140a7f9  [node]
2021-03-08T07:15:45.0450697Z ##[error]Der Vorgang wurde abgebrochen.

Ok JavaScript heap out of memory

pierre-gilles · 8. März 2021 um 07:41

Okay, offensichtlich ist der Speicherfehler eher eine Folge als ein Symptom des Problems…

Das Problem scheint mit sharp zusammenzuhängen, das Schwierigkeiten hat, wenn es zu viele Bilder gibt:

11:12:13 PM: (sharp:1883): GLib-GObject-WARNING **: 15:12:13.499: gtype.c:4265: type id '0' is invalid
11:12:13 PM: (sharp:1883): GLib-GObject-WARNING **: 15:12:13.499: can't peek value table for type '<invalid>' which is not currently referenced
11:12:13 PM: (sharp:1883): GLib-GObject-WARNING **: 15:12:13.499: gvalue.c:188: cannot initialize GValue with type '(null)', this type has no GTypeValueTable implementation

Was zu einer Endlosschleife, dann Speicherlecks und schließlich zu einem OOM-JS führt.

Falls jemand eine Idee hat, @VonOx oder @cicoub13, ich bin dankbar

Ich untersuche weiter, aber das ist wirklich mysteriös…

Edit: Wir sind nicht die Einzigen, das Problem existiert auch bei Gastby:

github.com/gatsbyjs/gatsby

Errors when processing large(ish) numbers of images with gatsby-plugin-sharp

ouvert 10:55AM - 04 Jul 18 UTC

fermé 04:03PM - 20 Mar 20 UTC

jp887

type: bug type: upstream

## Description I'm processing around 1500 images with gatsby-plugin-sharp/gat…sby-transformer-sharp and GraphQL, to display with gatsby-image as per [this page in the docs](https://www.gatsbyjs.org/packages/gatsby-image/). For smaller numbers of images I have had no issues, but now that I'm processing 1500 images the build randomly fails with the following error: ``` (sharp:104): GLib-GObject-WARNING **: 09:35:11.293: gtype.c:4265: type id '0' is invalid (sharp:104): GLib-GObject-WARNING **: 09:35:11.293: can't peek value table for type '<invalid>' which is not currently referenced (sharp:104): GLib-GObject-WARNING **: 09:35:11.293: gvalue.c:188: cannot initialize GValue with type '(null)', this type has no GTypeValueTable implementation (sharp:104): GLib-GObject-CRITICAL **: 09:35:11.293: g_value_transform: assertion 'G_IS_VALUE (src_value)' failed Received 'segmentation fault' signal ``` This happens during the "Generating image thumbnails" step in the build process and it occurs apparently randomly (sometimes 10% of the way through the images, sometimes at 80%, sometimes not at all). Therefore I do not believe it is caused by a "faulty image".

pierre-gilles · 8. März 2021 um 07:48

Ok, ich habe eine Spur.

Offensichtlich gibt es ein Problem mit den Versionen von sharp unter 0.27.1.

Aktuell verwenden wir mit der Version von Docusaurus, die wir nutzen, 0.22.1, daher das Problem.

VonOx · 8. März 2021 um 08:12

Ah, schau mal! Scharf!

Vor einigen Wochen haben @Terdious und @damalgos es auf den Netatmo-Dienst hinzugefügt, aber es ist unmöglich, die ARM-Images mit diesem Paket zu erstellen.

pierre-gilles · 8. März 2021 um 08:16

Also, ich bin dabei, Docusaurus auf die neueste Version zu aktualisieren, das ist nicht einfach, es gibt viele Breaking Changes ^^

VonOx · 8. März 2021 um 08:21

Ich bin gerade darüber gestolpert, und da die Aktion auf Ubuntu ausgeführt wird, könnte man es versuchen

github.com/lovell/sharp

Leak on Linux?

ouvert 10:59PM - 20 Sep 17 UTC

fermé 11:15AM - 19 May 18 UTC

asilvas

question

Been troubleshooting a leak in https://github.com/asilvas/node-image-steam (proc…esses millions of images every day) and originally thought it was in my project but after a number of heap dump checks I determined it wasn't a leak in V8. In order to break it down the simplest parts I recorded the traffic in a serial form so it can be replayed in a pure sharp script. https://gist.github.com/asilvas/474112440535051f2608223c8dc2fcdf ``` npm i sharp request curl https://gist.githubusercontent.com/asilvas/474112440535051f2608223c8dc2fcdf/raw/be4e593c6820c0246acf2dc9604012653d71c353/sharp.js > sharp.js curl https://gist.githubusercontent.com/asilvas/474112440535051f2608223c8dc2fcdf/raw/be4e593c6820c0246acf2dc9604012653d71c353/sharp.log > sharp.log node sharp.js http://img1.wsimg.com/isteam sharp.log ``` It's downloading these files on the fly, which avoids any FS caching which will bloat memory usage, and forwards the instructions (in sharp.log) directly to sharp, one at a time. Memory usage gets into 500MB+ within a few mins (at least on Docker+CentOS), and seems to eventually peak. On some systems I've seen over 2GB usage. Only processing a single image at a time should be pretty flat in memory usage. Have you seen this before? Any ideas? I wasn't aware of anything sharp/vips was doing that should be triggering Linux's file caching. *Edit:* While memory usage on Mac is still higher than I expect for a single image processed at a time (~160MB) after a couple hundred images, it's nowhere near as high as on Linux.. And it seems to peak quickly. So it *appears* to be a linux only issue. Docker is also involved, so not ruling that out either.

github.com/lovell/sharp

Reduce concurrency when using glibc-based Linux without jemalloc to help prevent memory fragmentation

ouvert 08:20PM - 04 Mar 21 UTC

fermé 02:17PM - 29 Mar 21 UTC

lbeschastny

enhancement ready-to-ship

After migrating from `gm` to `sharp` we noticed a strange behaviour of our image… processing servers. They memory consumption seemed inadequate and constantly growing. At first we suspected a memory lead in our JS code, but after some research it turned out that all this memory was consumed by either `sharp` or `libvips`. And it's not, strictly speaking, a leak, but rather a very strange and greedy memory allocation. Using node.js 14 partially negates the issue, but it's still there. **Are you using the latest version? Is the version currently in use as reported by `npm ls sharp` the same as the latest version as reported by `npm view sharp dist-tags.latest`?** Yes, `sharp@0.27.2` **What are the steps to reproduce?** Start processing some large images concurrently and memory consumption will grow very rapidly. At some point memory consumption will reach it's limit and will stay there. But increasing the size of processed images will result in further memory allocation. **What is the expected behaviour?** * `sharp` should limit it's memory usage with some sane threshold * `sharp` should free allocated memory whet it's no longer needed **Are you able to provide a minimal, standalone code sample, without other dependencies, that demonstrates this problem?** Here is a simple code example to illustrate strange memory consumption behaviour: ```js const sharp = require('sharp'); const filePath = '4ce2474a893e1e02e5f342808fe618a7.jpg'; const outputFormat = 'raw'; // raw format leaks memory faster const parallelTasks = 10; const totalTicks = 100; const bytesToMb = (bytes) => (bytes / Math.pow(1024, 2)).toFixed(2); // disable internal cache to increase mamory leaking speed sharp.cache(false); let pendingCount = 0; let ticksCount = 0; let errorsCount = 0; const tick = async (trials = 0) => { pendingCount += 1; try { await sharp(filePath).toFormat(outputFormat).toBuffer(); } catch (err) { console.log(err); errorsCount += 1; } finally { pendingCount -= 1; ticksCount += 1; const {rss, heapTotal} = process.memoryUsage(); process.stdout.clearLine(); process.stdout.cursorTo(0); process.stdout.write( `${ticksCount} ticks, ${errorsCount} errors, heap ${bytesToMb(heapTotal)}MB, rss ${bytesToMb(rss)}MB` ); if (ticksCount + pendingCount < totalTicks) { setTimeout(tick, 0); } } } Array(parallelTasks).fill().map(()=>{ tick(); }); ``` Here is a result of running this script on my system using node.js v12.18.1: ``` ↪ node test-memory.js 100 ticks, 0 errors, heap 8.48MB, rss 2105.86MB ``` You could use any `outputFormat`. I used `raw` because it leaks memory faster than compressed formats. At first I thought that the issue is related to `.toBuffer` internal buffering, but using files or streams will result in exactly the same memory consumption behaviour. Here is an example of running this script with `jpeg` format and an infinite total ticks threshold: ``` ↪ node test-memory.js 1606 ticks, 0 errors, heap 5.48MB, rss 1406.85MB ``` Memory consumption stops somewhere around this value, so it's not an actual leak. Doing the same with `raw` format results in node.js being killed by OOM killer after consuming all available memory. **Are you able to provide a sample image that helps explain the problem?** Any large image will do, here is the one I used in my tests: [![sample image](https://api.pcloud.com/getpubthumb?code=XZX74fXZKNlK2jnkvDX45jgUSoPuUHTekGLk&linkpassword=undefined&size=1860x1160&crop=0&type=auto)](https://u.pcloud.link/publink/show?code=XZX74fXZKNlK2jnkvDX45jgUSoPuUHTekGLk) **What is the output of running `npx envinfo --binaries --system`?** ``` System: OS: Linux 5.8 Ubuntu 20.04.2 LTS (Focal Fossa) CPU: (8) x64 Intel(R) Core(TM) i7-10510U CPU @ 1.80GHz Memory: 11.44 GB / 15.35 GB Container: Yes Shell: 5.0.17 - /bin/bash Binaries: Node: 12.18.1 - ~/.nvm/versions/node/v12.18.1/bin/node Yarn: 1.22.4 - ~/.nvm/versions/node/v12.18.1/bin/yarn npm: 6.14.5 - ~/.nvm/versions/node/v12.18.1/bin/npm ``` But the same behaviour could be reproduced using [node] docker container. I reproduced aforementioned issue using `node:8`, `node:10` and `node:12` containers. With `node:14` script output seems fine, but memory consumption is still high. And memory is still not released. But at least with `node:14` memory consumption lo longer goes through the roof. [node]: https://hub.docker.com/_/node/

pierre-gilles · 8. März 2021 um 08:25

Ich glaube nicht, dass wir etwas auf Systemebene tun müssen

Es gibt eindeutig einen Bug in der Version von sharp, die wir verwenden, und das echte Heilmittel ist, sharp zu aktualisieren!

VonOx · 8. März 2021 um 08:29

Ich bin einverstanden, ich versuche nur, die Sache zu entblocken

Übrigens habe ich gerade die Funktion yarn (kein äquivalentes npm soweit ich weiß) entdeckt, um eine Version für eine Abhängigkeit zu verwalten

"resolutions": {
    "sharp": "^0.27.1"
  }

pierre-gilles · 8. März 2021 um 09:49

Also, ich versuche schon seit mehreren Stunden, Docusaurus zu aktualisieren, und bin auf einige richtig tiefgehende Docusaurus-Bugs gestoßen

Sie haben ein Problem mit ihrer Joi-Validierung, die erwartet, dass « prependBaseUrlToHref » ein String ist, während in ihrer Dokumentation steht, dass es ein Boolean ist (was Sinn ergeben würde)…

github.com/facebook/docusaurus

packages/docusaurus-theme-classic/src/validateThemeConfig.js

333545aa9


      
          };
          exports.DEFAULT_CONFIG = DEFAULT_CONFIG;
          
          const NavbarItemPosition = Joi.string().equal('left', 'right').default('left');
          
          const BaseNavbarItemSchema = Joi.object({
            to: Joi.string(),
            href: URISchema,
            label: Joi.string(),
            className: Joi.string(),
            prependBaseUrlToHref: Joi.string(),
          })
            // We allow any unknown attributes on the links
            // (users may need additional attributes like target, aria-role, data-customAttribute...)
            .unknown();
          
          // TODO we should probably create a custom navbar item type "dropdown"
          // having this recursive structure is bad because we only support 2 levels
          // + parent/child don't have exactly the same props
          const DefaultNavbarItemSchema = BaseNavbarItemSchema.append({
            items: Joi.array().optional().items(BaseNavbarItemSchema),

Das riecht nach einem PR für Docusaurus…

pierre-gilles · 8. März 2021 um 10:03

Issue bei Docusaurus erstellt: "prependBaseUrlToHref" is defined as a string in Joi validation, and it's supposed to be a boolean in the doc · Issue #4363 · facebook/docusaurus · GitHub

Ich werde heute keine Pull Request für sie machen, erstmal habe ich ihnen ein Issue erstellt und wir werden sehen, was sie sagen..

In der Zwischenzeit denke ich, dass wir blockiert sind. Wir können nicht auf die neueste Version wechseln ^^

pierre-gilles · 18. März 2021 um 06:22

Für Info, die neueste Version von Docusaurus (alpha-72) unterstützt Internationalisierung!

Heute versuche ich also, auf diese Version umzusteigen, das sieht wirklich stylisch aus

Übrigens habe ich festgestellt, dass der Hauptentwickler dieses Projekts Franzose ist und ich bin in einer Gruppe mit ihm ^^

pierre-gilles · 18. März 2021 um 07:47

Für alle, die mitverfolgen wollen, hier ist der Pull Request:

Die Arbeit ist riesig, ich glaube, das wird mich eine Weile beschäftigen.

cicoub13 · 18. März 2021 um 09:28

Super Initiative. Könntest du das nicht in zwei Schritten machen? Zuerst die Versionen auf Englisch und Französisch aktualisieren und dann die Internationalisierung aktivieren?

Nicht viel Zeit, um dir zu helfen, aber zum Testen ja

pierre-gilles · 18. März 2021 um 09:33

Es gibt trotzdem noch einige Unterschiede, da die API noch in der Alpha-Phase ist, hat sie sich zwischen der Version, die wir verwendet haben, und der aktuellen Version 72 stark verändert.

Auf jeden Fall habe ich angefangen Ich habe ein leeres Docusaurus-Projekt erstellt und habe alles schrittweise hineinkopiert. Ich habe fast die englische Version des Sites funktioniert.

Als nächstes muss ich die FR-Übersetzungsdateien generieren und die Übersetzungen von der aktuellen Website kopieren. Es ist etwas Kleinarbeit, aber es muss gemacht werden ^^

pierre-gilles · 19. März 2021 um 05:08

Boah, ich habe den ganzen Morgen daran gearbeitet, die Website läuft endlich!!

Ich musste alle Teile der Dokumentation übersetzen, die auf Französisch, aber nicht auf Englisch vorhanden waren.

Ehrlich gesagt, diese neue Version von Docusaurus ist wirklich stylisch, sie erkennt tote Links, Bilder, die ins Leere verweisen, es ist wirklich gut gemacht. Dank dessen habe ich viele Probleme auf der Website gefunden

pierre-gilles · 19. März 2021 um 06:37

Hop, eine Vorschau der Website für alle, die testen möchten:

[EDIT: Die Website ist live! => https://gladysassistant.com/ zum Testen!]

Also:

Die Wurzel der Website ist nun die englische Version der Website
Unter « /fr » gibt es die französische Version der Website
Ich musste alle FR-Artikel, die nicht auf der englischen Website waren, übertragen. Einige habe ich übersetzt, aber nicht alle, weil das wirklich lange dauert… ^^

Normalerweise gibt es bei der Dokumentation vollständige Parität zwischen der FR- und der EN-Version der Website (alles übersetzt :p)

Lasst mich wissen, was ihr davon haltet!

pierre-gilles · 19. März 2021 um 07:27

Okay, ich habe die Website online gestellt, für mich ist das schon viel besser als vorher

Meldet euch, wenn ihr etwas seht, ich schaue auf meiner Seite weiter!

Thema		Antworten	Aufrufe
Un nouveau site pour Gladys 4? Développement	30	3014	21. Juli 2020
Gladys Assistant: Ecrivons plus de contenu ensemble! Développement	65	1449	17. Mai 2024
Le chemin vers Gladys 4 RC Actualités	25	2515	1. Dezember 2020
Rendre les menus homogène Développement	34	1511	24. Januar 2024
Point PR janvier 2023 Développement	19	915	20. Januar 2023

[Site Docusaurus Gladys] Build fehlt seit den letzten Airtable-Änderungen

Verwandte Themen