How is it going? Are you still on 2.12? Are you considering 2.13? Have you tried using the 3.0 alpha?
1 Like
Sorry for the late reply. I actually came across several packages, including Accounts, that still caused fiber warnings. On some I did a PR (like roles) and some I replaced with my own code (like meteor-tenancy). Meteor files is also an important package I think.
I didn’t yet upgrade to 2.13. Will give it a shot on my staging env on scalingo to see if building the app works as expected
2 Likes
Keep me informed. We mentioned this post in the MeteorJS Dispatches podcast.
1 Like
I did post about my progress of upgrading WeKan to Meteor 3.0 alpha 15 here:
2 Likes
Brief update:
- PR for Meteor-Files is in the making, beta is out.
- The only remaining warnings with
WARN_WHEN_USING_OLD_API=truecome from theaccounts-passwordpackage - Got some trouble with updating to alpha resp. beta (cf. this thread)
2 Likes
Great job. Keep up the good work! 
Consider cross posting here for reference
https://forums.meteor.com/t/looking-for-help-migrating-packages-to-meteor-3-0/
Yay! Got the first boot up of my app on meteor 3.0 beta! Wow! Worked around this issue by removing and re-adding packages step-by-step.
First a got a bit stuck at aldeed:collection2, didn’t read that you need to import 'meteor/aldeed:collection2/static'; to keep things working as before.
Now I’m a bit stuck with this problem here, related to Meteor.userAsync() calls from within publications, that throw an error. Will try to get a minimal reproducible example ready.
1 Like
This may be a very old thread, but I just wanted to add: All 1500+ server tests successfully passed under 3.0.2. What a day! Thanks to everyone who helped make Meteor 3.0 possible! 
7 Likes
That’s awesome! Congrats
1 Like
Thanks for paving the path and sharing your experience. How did you replace meteorhacks:picker?
It’s no longer needed, Meteor 3.0 uses express under the hood.
Next big step accomplished. Just deployed my meteor 3.0.3 update in my staging env at scalingo. Now some end-to-end testing before deploying to production.
2 Likes
Finally! Updated my app to 3.0.4. Everything’s looking good except from memory consumption. Needed to scale up in order to keep my containers running, that’s really a bummer. Has anyone any advice how to profile memory consumption? I’d really like to optimize this, I suspect that observers eat up more memory, but I don’t know a way to analyze this in detail.
We’ve released the beta for 3.1.1, featuring Meteor runtime performance improvements, including reduced RAM usage. When the official version is out, we’ll share detailed benchmarks report and comparisons with earlier versions.
In the meantime, if you can help with testing, update your app and let us know if you notice any improvements in RAM usage.
meteor update --release 3.1.1-beta.1
2 Likes
Hello,
I have just installed it and i noticed a few of this errors at my app startup :
allow: The "updateAsync" key is deprecated. Use "update" instead.
deny: The "insertAsync" key is deprecated. Use "insert" instead.
Do you know if something has changed here ?
Yes, we did a deprecation on allow/deny rules, to only enable insert, update and remove rules, with async validation option.
However, it seems that if it isn’t your direct app code, it may be related with a package using async rules and not migrated. We may consider to remove these warnings if it is the case, and treat the deprecation as a changelog item. In a future minor version we will completely remove those rules, but we would like app or packages affected to migrate already.
I’ll definitely try this, as soon as I can use montiapm on 3.1. Also, I’m quite sure that after updating to 3.0.4 from 2.16 I introduced memory leaks, since RAM keeps constantly increasing over a busy day. I already checked several “.observe” calls and checked whether the handlers got stopped.
Any hint where the transition from 2.16 to 3.0.4 could possibly introduce memory leaks? Any tools that I can use to investigate which function or variables pile up in memory? My codebase is quite large, I need to find out where to look at…
Ok thanks, this comes probably from a package because I only use this in my code :
blabla.deny({
insert() {
return true;
},
update() {
return true;
},
remove() {
return true;
}
});
@bratelefant you had memory consumptions issues in the past ([SOLVED] Meteor server memory leaks / profiling)
Meteor 2.8.1 had a mongo driver problem which was seen in memory increasing over time: Meteor v2.8 - Memory leak in mongo driver?
A very low-use project, 1-2 users now and then (second image).
Low point on the memory usage is the time of redeploy. Something is growing slowly. I was almost at the limit of memory per processor. This is Meteor 3.1.
I have other projects on Meteor 3.1 which are fine. (first image)
I downgraded to 3.0.4 to see if there are any changes but will need to wait for a while until I can see the pattern.
Both projects run on similar machines (t3.micro with 512MB per processor, with 2 x vCPU)
Will see how this one goes the next 2-3 days.
Thanks for sharing your experiences. Yes, I had memory leaks in the past, got them solved so far. As long as I’m on 2.16 everything looked fine, no more increasing memory consumption. Disconnecting client whenever possible. Now in my current setup stuff looks like this. On an increaing number of sessions (it’s around 30-50 on normal days) memory piles up. You see the restarts of the web container and a clear tendency of increasing memory consumption; the other one is a queue worker, that one is ok so far.
