nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

100% CPU Usage after startup

trent

Hi guys,

I've got 100% CPU usage on one of my CPUs after startup of tomcat 5.

I installed using the WAR, and have mysql running.

I edited the database configuration, and the data folder configuration, and put the entire contents of "extensions" in common/shared/classes/alfresco.

I'm not getting any more errors in any tomcat logs, but the one CPU has been running at 100% since startup about 10 minutes ago.

I am unable to access any of my tomcat contexts, so obviously it must be stuck in a static initializer somewhere. It's almost like there must be an infinite loop or something.

FYI: At first I was getting an out of memory error, but resolved that with the following…
-server -Xmx512m -Xms512m -XX:MaxPermSize=64m -XX

ermSize=64m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled

Any help would be appreciated. I'd like to try out Alfresco to see if it's worth using for my web site content.

Find more posts tagged with

Comments

trent

Oh, by the way, it did create the files in the data directory just fine, and it did create the tables in the mysql database. So file permissions, and mysql connections seem just fine.

kevinr

The first time you start the Alfresco server it will create the initial database schema automatically - this normally takes a couple of minutes. Sounds like yours is taking a lot longer - what is the machine spec? Also do you have a lot (maybe DEBUG) logging turned on? As by default some of the open-source libraries used by Alfresco generate a lot of DEBUG level logging which could slow down the server…

Thanks,

Kevin

trent

The first time you start the Alfresco server it will create the initial database schema automatically - this normally takes a couple of minutes. Sounds like yours is taking a lot longer - what is the machine spec? Also do you have a lot (maybe DEBUG) logging turned on? As by default some of the open-source libraries used by Alfresco generate a lot of DEBUG level logging which could slow down the server…

Thanks,

Kevin

Hi Kevin,

There is no output to any logs in the tomcat log directory, except to say that the context is being initialized. I waited approximately 45 minutes before killing the process.

I have a Duo Core Athlon 64 CPU. The system is pretty fast, and has 2G of memory, although I only allocated 1G to the Xen VM, once I realized I was running out of memory. I am no longer getting out of memory errors.

processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 75
model name      : AMD Athlon™ 64 X2 Dual Core Processor 3800+
stepping        : 2
cpu MHz         : 2004.202

However, I just thought of something. Perhaps I need to wipe the database again. Maybe it ran out of memory in the middle of the initialization, and completely messed things up. What do you think?

kevinr

The machine is more than enough

my Core2 laptop can bootstrap the server in about 60 seconds. Yes i would try creating the db schema instance and removing the alf_data dir contents.

Thanks,

Kevin

sbzoom

This happened to me as well. I had two installations, one RedHat, the other Windows. The RedHat install runs great. The Windows one I gave up on a while ago. Everything seemed fine until someone visited the homepage. Once someone accesses the application, the CPU spiked to 100% and stayed that for… for DAYS. I'd stop all processes and try again, same effect. So I just gave up on windows - things run great on linux.

Charlie

trent

This happened to me as well. I had two installations, one RedHat, the other Windows. The RedHat install runs great. The Windows one I gave up on a while ago. Everything seemed fine until someone visited the homepage. Once someone accesses the application, the CPU spiked to 100% and stayed that for… for DAYS. I'd stop all processes and try again, same effect. So I just gave up on windows - things run great on linux.

Charlie

I'm having this issue on Linux. But, I'm not running RedHat, I'm running gentoo.

devg

Was this issue ever resolved? This is happening to us on Linux and we already have a database/repository with lots of file data, so I don't want to start from scratch.

When I did full index recovery, it took almost 7 hours to finish, but right after saying 100% recovery complete, it went into this inifinite loop. Now it happens every time I restart - I don't want to try another index recovery becuase it takes 7 hours.

I recently upgraded to 2.1 from 2.0 - it worked fine for about a day after that.

Any help is appreciated.

This happened to me as well. I had two installations, one RedHat, the other Windows. The RedHat install runs great. The Windows one I gave up on a while ago. Everything seemed fine until someone visited the homepage. Once someone accesses the application, the CPU spiked to 100% and stayed that for… for DAYS. I'd stop all processes and try again, same effect. So I just gave up on windows - things run great on linux.

Charlie

I'm having this issue on Linux. But, I'm not running RedHat, I'm running gentoo.

trent

No, I never resolved the issue. I kind of just gave up. I was hoping for an easy to use, easy to install, content management system. I just wanted to use it to maintain my own site. But, I think Alfresco is over kill for my needs.

kevinr

This happened to me as well. I had two installations, one RedHat, the other Windows. The RedHat install runs great. The Windows one I gave up on a while ago. Everything seemed fine until someone visited the homepage. Once someone accesses the application, the CPU spiked to 100% and stayed that for… for DAYS. I'd stop all processes and try again, same effect. So I just gave up on windows - things run great on linux.

We haven't had any customers report this. About half of our developers use Windows laptops also and haven't seen this. We'd really appreciate if when you see this happening, you press CTRL+BREAK to output a thread dump report into your console window then either email us or post the report here.

Thanks,

Kevin

andy

Hi

What database are you using?

Andy

francescof

When I did full index recovery, it took almost 7 hours to finish, but right after saying 100% recovery complete, it went into this inifinite loop. Now it happens every time I restart - I don't want to try another index recovery becuase it takes 7 hours.

I recently upgraded to 2.1 from 2.0 - it worked fine for about a day after that.

Any help is appreciated.

It is not an infinite loop…

We had similar problem full reindexing a repository with something like 40K contents: it takes about 13-15 minutes to say 100% recovery complete and then it starts to call getPaths() on every node in the repository. Forcing a backtrace dump in getPaths() it seems that it is doing a lot of work to commit the whole big reindex transaction: all the commit work is done AFTER returning from the method which implements the reindexing: this is why the log says "100% recovery complete". The end result, for me, is that after some time i get an "Out of Memory" exception (with -Xmx512m).

In conclusion: what you called "infinite loop" is really part of the reindexing. I think that the real problems here are:

1) Keep as low as possible the memory usage during reindex… perhaps splitting the reindex transaction in parts?
2) Implement an incremental reindex strategy: there are cases in which you know that your index are not corrupted, but they are just not up-to-date with the last transaction. So, why not replaying from the first missing transaction to the last one?

Restoring a backup of a hundred thousands contents seems impossible nowadays… perhaps point 2 is already in place but I can't figure out how to enable it.

ssleong

that might explain what i'm seeing with my CPUs - they continued
being busy 18 hours after the indexing process completed. as i write, they're still plugging away.

my upgrade was from 1.4 to 2.1 , the indexing took 5 hours for 441,000+ records. the upgrade is in the DEV environment and i am going to leave it to run. at some point, we will have to upgrade the production version. is there any way of speeding thing up ?

Regards,
See-See

———————————————————————————-
Database    : Oracle 10g
OS              : RedHat
JVM values : -Xms129m -Xmx1024m -server -XX:MaxPermSize=128m

———————————————————————————-

LOGS :

10:45:18,226 INFO [org.alfresco.repo.node.index.FullIndexRecoveryComponent] Index recovery started: 441,549 transactions.

11:09:01,439 INFO [org.alfresco.repo.node.index.FullIndexRecoveryComponent]    20 % complete.
11:26:44,001 INFO [org.alfresco.repo.node.index.FullIndexRecoveryComponent]    30 % complete.
11:49:51,939 INFO [org.alfresco.repo.node.index.FullIndexRecoveryComponent]    40 % complete.
12:18:07,786 INFO [org.alfresco.repo.node.index.FullIndexRecoveryComponent]    50 % complete.
12:53:08,612 INFO [org.alfresco.repo.node.index.FullIndexRecoveryComponent]    60 % complete.
13:30:53,164 INFO [org.alfresco.repo.node.index.FullIndexRecoveryComponent]    70 % complete.
14:12:04,777 INFO [org.alfresco.repo.node.index.FullIndexRecoveryComponent]    80 % complete.
15:03:15,351 INFO [org.alfresco.repo.node.index.FullIndexRecoveryComponent]    90 % complete.
15:43:09,418 INFO [org.alfresco.repo.node.index.FullIndexRecoveryComponent]    100 % complete.
15:43:09,420 INFO [org.alfresco.repo.node.index.FullIndexRecoveryComponent] Index recovery completed.

Current Time : 09:24 (next day)

———————————————————————————-
CPU states: cpu    user    nice system    irq softirq iowait    idle
           total   22.2%    0.0%    5.9%   0.0%     0.1%    0.0%   71.6%
           cpu00   20.1%    0.0%    5.7%   0.0%     0.0%    0.0%   74.0%
           cpu01   29.8%    0.0%    8.6%   0.0%     0.0%    0.0%   61.5%
           cpu02   20.7%    0.0%    5.7%   0.0%     0.4%    0.0%   72.9%
           cpu03   18.3%    0.0%    3.3%   0.0%     0.0%    0.0%   78.2%

———————————————————————————–

Indexes on the Alfresco schema

INDEX_NAME                     TABLE_NAME
—————————— ——————————
ADT_DATE_IDX                   ALF_AUDIT_DATE
ADT_DOM_IDX                    ALF_AUDIT_DATE
ADT_DOW_IDX                    ALF_AUDIT_DATE
ADT_DOY_IDX                    ALF_AUDIT_DATE
ADT_HY_IDX                     ALF_AUDIT_DATE
ADT_M_IDX                      ALF_AUDIT_DATE
ADT_Q_IDX                      ALF_AUDIT_DATE
ADT_STORE_IDX                  ALF_AUDIT_FACT
ADT_USER_IDX                   ALF_AUDIT_FACT
ADT_WOM_IDX                    ALF_AUDIT_DATE
ADT_WOY_IDX                    ALF_AUDIT_DATE
ADT_Y_IDX                      ALF_AUDIT_DATE
APP_SOURCE_APP_IDX             ALF_AUDIT_SOURCE
APP_SOURCE_MET_IDX             ALF_AUDIT_SOURCE
APP_SOURCE_SER_IDX             ALF_AUDIT_SOURCE
FK335CAE262C5AB86C             ALF_MAP_ATTRIBUTE_ENTRIES
FK335CAE26AEAC208C             ALF_MAP_ATTRIBUTE_ENTRIES
FK44A37C8A6BD529F3             AVM_NODE_PROPERTIES_NEW
FK60EFB626B9553F6C             ALF_NODE
FK60EFB626D24ADD25             ALF_NODE
FK71C2002B7F2C8017             ALF_NODE_STATUS
FK71C2002B9E57C13D             ALF_NODE_STATUS
FK7D4CF8EC40E780DC             ALF_NODE_PROPERTIES
FK7D4CF8EC7F2C8017             ALF_NODE_PROPERTIES
FK8A749A657B7FDE43             ALF_AUTH_EXT_KEYS
FKB8761A3A9AE340B7             ALF_TRANSACTION
FKBD4FF53D22DBA5BA             ALF_STORE
FKC7D52FB02C5AB86C             ALF_LIST_ATTRIBUTE_ENTRIES
FKC7D52FB0ACD8822C             ALF_LIST_ATTRIBUTE_ENTRIES
FKD3FD9F95EDCD4A96             AVM_ASPECTS_NEW
FKD654E027F2C8017              ALF_NODE_ASPECTS
FKE1A550BCA8FC7769             ALF_NODE_ASSOC
FKE1A550BCB69C43F3             ALF_NODE_ASSOC
FKEAD1817484342E39             ALF_AUDIT_FACT
FKEAD18174A0F9B8D9             ALF_AUDIT_FACT
FKEAD18174F524CFD7             ALF_AUDIT_FACT
FKFFC5468E74173FF4             ALF_CHILD_ASSOC
FKFFC5468E8E50E582             ALF_CHILD_ASSOC
FKFFF41F9960601995             ALF_ACCESS_CONTROL_ENTRY
FKFFF41F99B25A50BF             ALF_ACCESS_CONTROL_ENTRY
FKFFF41F99B9553F6C             ALF_ACCESS_CONTROL_ENTRY
FK_ATTR_N_ACL                  ALF_ATTRIBUTES
FK_AVM_ASP_NODE                AVM_ASPECTS
FK_AVM_CE_CHILD                AVM_CHILD_ENTRIES
FK_AVM_CE_PARENT               AVM_CHILD_ENTRIES
FK_AVM_HL_ANCESTOR             AVM_HISTORY_LINKS
FK_AVM_HL_DESC                 AVM_HISTORY_LINKS
FK_AVM_ML_FROM                 AVM_MERGE_LINKS
FK_AVM_ML_TO                   AVM_MERGE_LINKS
FK_AVM_NP_NODE                 AVM_NODE_PROPERTIES
FK_AVM_N_ACL                   AVM_NODES
FK_AVM_N_STORE                 AVM_NODES
FK_AVM_SP_STORE                AVM_STORE_PROPERTIES
FK_AVM_S_ROOT                  AVM_STORES
FK_AVM_VR_ROOT                 AVM_VERSION_ROOTS
FK_AVM_VR_STORE                AVM_VERSION_ROOTS
IDX_ACTION_ACTNDL              JBPM_ACTION
IDX_ACTION_EVENT               JBPM_ACTION
IDX_ACTION_PROCDF              JBPM_ACTION
IDX_ASSOC                      ALF_NODE_ASSOC
IDX_AVM_NP_NAME                AVM_NODE_PROPERTIES
IDX_AVM_SP_NAME                AVM_STORE_PROPERTIES
IDX_AVM_VR_VERSION             AVM_VERSION_ROOTS
IDX_CHILD_NAMECRC              ALF_CHILD_ASSOC
IDX_COMMENT_TOKEN              JBPM_COMMENT
IDX_COMMENT_TSK                JBPM_COMMENT
IDX_DELEG_PRCD                 JBPM_DELEGATION
IDX_JOB_PRINST                 JBPM_JOB
IDX_JOB_TOKEN                  JBPM_JOB
IDX_JOB_TSKINST                JBPM_JOB
IDX_MODDEF_PROCDF              JBPM_MODULEDEFINITION
IDX_MODINST_PRINST             JBPM_MODULEINSTANCE
IDX_NODE_ACTION                JBPM_NODE
IDX_NODE_PROCDEF               JBPM_NODE
IDX_NODE_SUPRSTATE             JBPM_NODE
IDX_PLDACTR_ACTID              JBPM_POOLEDACTOR
IDX_PROCDEF_STRTST             JBPM_PROCESSDEFINITION
IDX_PROCIN_PROCDEF             JBPM_PROCESSINSTANCE
IDX_PROCIN_ROOTTK              JBPM_PROCESSINSTANCE
IDX_PROCIN_SPROCTK             JBPM_PROCESSINSTANCE
IDX_PSTATE_SBPRCDEF            JBPM_NODE
IDX_RTACTN_ACTION              JBPM_RUNTIMEACTION
IDX_RTACTN_PRCINST             JBPM_RUNTIMEACTION
IDX_SWIMLINST_SL               JBPM_SWIMLANEINSTANCE
IDX_TASKINST_TOKN              JBPM_TASKINSTANCE
IDX_TASKINST_TSK               JBPM_TASKINSTANCE
IDX_TASK_ACTORID               JBPM_TASKINSTANCE
IDX_TASK_PROCDEF               JBPM_TASK
IDX_TASK_TASKMGTDF             JBPM_TASK
IDX_TASK_TSKNODE               JBPM_TASK
IDX_TKVARMAP_CTXT              JBPM_TOKENVARIABLEMAP
IDX_TKVVARMP_TOKEN             JBPM_TOKENVARIABLEMAP
IDX_TOKEN_NODE                 JBPM_TOKEN
IDX_TOKEN_PARENT               JBPM_TOKEN
IDX_TOKEN_PROCIN               JBPM_TOKEN
IDX_TOKEN_SUBPI                JBPM_TOKEN
IDX_TRANSIT_FROM               JBPM_TRANSITION
IDX_TRANSIT_TO                 JBPM_TRANSITION
IDX_TRANS_PROCDEF              JBPM_TRANSITION
IDX_TSKINST_SLINST             JBPM_TASKINSTANCE
IDX_TSKINST_SWLANE             JBPM_POOLEDACTOR
IDX_TSKINST_TMINST             JBPM_TASKINSTANCE
IDX_VARINST_PRCINS             JBPM_VARIABLEINSTANCE
IDX_VARINST_TK                 JBPM_VARIABLEINSTANCE
IDX_VARINST_TKVARMP            JBPM_VARIABLEINSTANCE
SS_IDX_ALF_TRANSACTION         ALF_TRANSACTION
SYS_C0021810                   ALF_APPLIED_PATCH
SYS_C0022135                   ALF_ACCESS_CONTROL_ENTRY
SYS_C0022136                   ALF_ACCESS_CONTROL_ENTRY
SYS_C0022139                   ALF_ACCESS_CONTROL_LIST
SYS_C0022142                   ALF_AUTH_EXT_KEYS
SYS_C0022144                   ALF_AUTHORITY
SYS_C0022148                   ALF_CHILD_ASSOC
SYS_C0022154                   ALF_NODE
SYS_C0022155                   ALF_NODE
SYS_C0022159                   ALF_NODE_ASSOC
SYS_C0022164                   ALF_NODE_STATUS
SYS_C0022168                   ALF_PERMISSION
SYS_C0022169                   ALF_PERMISSION
SYS_C0022172                   ALF_STORE
SYS_C0022176                   ALF_VERSION_COUNT
SYS_C0022177                   ALF_NODE_PROPERTIES
SYS_C0022197                   ALF_SERVER
SYS_C0022198                   ALF_SERVER
SYS_C0022201                   ALF_TRANSACTION
SYS_C0022207                   JBPM_ACTION
SYS_C0022209                   JBPM_BYTEARRAY
SYS_C0022212                   JBPM_BYTEBLOCK
SYS_C0022215                   JBPM_COMMENT
SYS_C0022218                   JBPM_DECISIONCONDITIONS
SYS_C0022220                   JBPM_DELEGATION
SYS_C0022222                   JBPM_EVENT
SYS_C0022224                   JBPM_EXCEPTIONHANDLER
SYS_C0022227                   JBPM_LOG
SYS_C0022230                   JBPM_MESSAGE
SYS_C0022233                   JBPM_MODULEDEFINITION
SYS_C0022236                   JBPM_MODULEINSTANCE
SYS_C0022239                   JBPM_NODE
SYS_C0022241                   JBPM_POOLEDACTOR
SYS_C0022243                   JBPM_PROCESSDEFINITION
SYS_C0022246                   JBPM_PROCESSINSTANCE
SYS_C0022249                   JBPM_RUNTIMEACTION
SYS_C0022251                   JBPM_SWIMLANE
SYS_C0022253                   JBPM_SWIMLANEINSTANCE
SYS_C0022255                   JBPM_TASK
SYS_C0022258                   JBPM_TASKACTORPOOL
SYS_C0022260                   JBPM_TASKCONTROLLER
SYS_C0022263                   JBPM_TASKINSTANCE
SYS_C0022265                   JBPM_TIMER
SYS_C0022268                   JBPM_TOKEN
SYS_C0022270                   JBPM_TOKENVARIABLEMAP
SYS_C0022272                   JBPM_TRANSITION
SYS_C0022274                   JBPM_VARIABLEACCESS
SYS_C0022277                   JBPM_VARIABLEINSTANCE
SYS_C0022280                   ALF_AUDIT_CONFIG
SYS_C0022292                   ALF_AUDIT_DATE
SYS_C0022302                   ALF_AUDIT_FACT
SYS_C0022305                   ALF_AUDIT_SOURCE
SYS_C0022402                   JBPM_JOB
SYS_C0022406                   ALF_ATTRIBUTES
SYS_C0022408                   ALF_GLOBAL_ATTRIBUTES
SYS_C0022409                   ALF_GLOBAL_ATTRIBUTES
SYS_C0022412                   ALF_LIST_ATTRIBUTE_ENTRIES
SYS_C0022415                   ALF_MAP_ATTRIBUTE_ENTRIES
SYS_C0022417                   AVM_ASPECTS
SYS_C0022420                   AVM_ASPECTS_NEW
SYS_C0022424                   AVM_CHILD_ENTRIES
SYS_C0022427                   AVM_HISTORY_LINKS
SYS_C0022430                   AVM_MERGE_LINKS
SYS_C0022435                   AVM_NODE_PROPERTIES
SYS_C0022441                   AVM_NODE_PROPERTIES_NEW
SYS_C0022452                   AVM_NODES
SYS_C0022457                   AVM_STORE_PROPERTIES
SYS_C0022461                   AVM_STORES
SYS_C0022462                   AVM_STORES
SYS_C0022465                   AVM_VERSION_LAYERED_NODE_ENTRY
SYS_C0022472                   AVM_VERSION_ROOTS
SYS_C0022473                   AVM_VERSION_ROOTS

178 rows selected

ssleong

Francescof ,

what you said is true, what appears to be an infinite loop (after the indexes get created) isnt. in my case, the 'loop' ran for 3 days 3 hours a
and 38 minutes before Alfresco started up !

Regards,
See-See

———————————————————————-

Oct 24
10:45:03,298 WARN [org.springframework.remoting.rmi.RmiRegistryFactoryBean] Could not detect RMI registry - creating new one
10:45:05,156 WARN [org.alfresco.util.OpenOfficeConnectionTester] A connection to OpenOffice could not be established.
10:45:07,057 INFO [org.alfresco.repo.domain.schema.SchemaBootstrap] Schema managed by database dialect org.hibernate.dialect.Oracle9Dialect.
10:45:14,319 INFO [org.alfresco.repo.domain.schema.SchemaBootstrap] No changes were made to the schema.
10:45:18,226 INFO [org.alfresco.repo.node.index.FullIndexRecoveryComponent] Index recovery started: 441,549 transactions.
10:55:34,878 INFO [org.alfresco.repo.node.index.FullIndexRecoveryComponent]    10 % complete.
11:09:01,439 INFO [org.alfresco.repo.node.index.FullIndexRecoveryComponent]    20 % complete.
11:26:44,001 INFO [org.alfresco.repo.node.index.FullIndexRecoveryComponent]    30 % complete.
11:49:51,939 INFO [org.alfresco.repo.node.index.FullIndexRecoveryComponent]    40 % complete.
12:18:07,786 INFO [org.alfresco.repo.node.index.FullIndexRecoveryComponent]    50 % complete.
12:53:08,612 INFO [org.alfresco.repo.node.index.FullIndexRecoveryComponent]    60 % complete.
13:30:53,164 INFO [org.alfresco.repo.node.index.FullIndexRecoveryComponent]    70 % complete.
14:12:04,777 INFO [org.alfresco.repo.node.index.FullIndexRecoveryComponent]    80 % complete.
15:03:15,351 INFO [org.alfresco.repo.node.index.FullIndexRecoveryComponent]    90 % complete.
15:43:09,418 INFO [org.alfresco.repo.node.index.FullIndexRecoveryComponent]    100 % complete.
15:43:09,420 INFO [org.alfresco.repo.node.index.FullIndexRecoveryComponent] Index recovery completed.

——————
Oct 27

18:36:00,055 INFO [org.alfresco.repo.admin.ConfigurationChecker] The Alfresco root data directory ('dir.root') is: /mnt/appcdev/knowledgebank/alfresco/alf_data
18:36:00,112 INFO [org.alfresco.repo.admin.patch.PatchExecuter] Checking for patches to apply …
19:23:11,453 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.db-V2.1-NotNullColumns
RESULT:
Script completed
=====================================
19:23:11,454 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.db-V2.1-FKIndexes
RESULT:
Script completed
=====================================
19:23:11,454 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.db-V2.1-ExplicitIndexes
RESULT:
Script completed
=====================================
19:23:11,454 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.db-V2.1-ExplicitIndexes
RESULT:
Script completed
=====================================
19:23:11,454 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.db-V2.1-JBPMUpdate
RESULT:
Script completed
=====================================
19:23:11,454 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.db-V2.1-VersionColumns2
RESULT:
Script completed
=====================================
19:23:11,454 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.db-V2.1-JBPMProcessKey
RESULT:
Script completed
=====================================

19:23:11,454 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.InvalidNameEnding
RESULT:
Fixed 73 names ending with a space or full stop. See file ./InvalidNameEndingPatch.log for details.
=====================================
19:23:11,454 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.systemDescriptorContent
RESULT:
Added the version properties content to the system descriptor.
=====================================
19:23:11,454 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.multilingualBootstrap
RESULT:
Imported view into bootstrap location: / (workspace://SpacesStore/d60d40d9-9a43-11da-98d8-ebbb2fa0f9f3)
=====================================
19:23:11,455 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.authoritiesFolderPermission
RESULT:
Imported view into bootstrap location: /sys:system (user://alfrescoUserStore/d4326650-9a43-11da-98d8-ebbb2fa0f9f3)
=====================================
19:23:11,455 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.LinkNodeFileExtension
RESULT:
Fixed 0 link node file extensions. See file ./LinkNodeExtensionPatch.log for details.
=====================================
19:23:11,455 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.systemRegistryBootstrap
RESULT:
Imported view into bootstrap location: / (system://system/d3ddddad-9a43-11da-98d8-ebbb2fa0f9f3)
=====================================
19:23:11,455 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.userAndPersonUserNamesAsIdentifiers
RESULT:
Reindexed user:user and cm

erson uids as identifiers

=====================================
19:23:11,455 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.contentFormFolderType
RESULT:
Updated 0 WCM Content Form objects to wcm:formfolder type.
=====================================
19:23:11,455 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.versionHistoryPerformance
RESULT:
Updated 19,238 version history objects to improv* performance.
=====================================
19:23:11,455 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.webscripts
RESULT:
Imported view into bootstrap location: /app:company_home/app:dictionary (workspace://SpacesStore/d60d40d9-9a43-11da-98d8-ebbb2fa0f9f3)
=====================================
19:23:11,455 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.groupNamesAsIdentifiers
RESULT:
Reindexed usr:authorityContainer with identifiers
=====================================
19:23:11,455 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.invalidUserPersonAndGroup
RESULT:
Fixed '0' invalid user nodes, '0' invalid person nodes and '0' invalid authority nodes.
=====================================
19:23:11,455 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.AVMGuidPatch
RESULT:
AVM GUIDS set.
=====================================
19:23:11,455 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.webscriptsExtension
RESULT:
Imported view into bootstrap location: /app:company_home/app:dictionary (workspace://SpacesStore/d60d40d9-9a43-11da-98d8-ebbb2fa0f9f3)
=====================================

19:23:11,456 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.AVMLayeredSnapshot
RESULT:
Layered Node indirectionVersions set.
=====================================
19:23:11,456 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.groupMembersAsIdentifiers
RESULT:
Reindexed usr:authorityContainer with identifiers
=====================================
19:23:11,456 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.redeploySubmitProcess
RESULT:
Re-deployed 1 workflows.
=====================================
19:23:11,456 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.AVMLocking
RESULT:

Necessary web projects added.
=====================================
19:23:11,456 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.ReadmeTemplate
RESULT:
Imported view into bootstrap location: /app:company_home/app:dictionary/app:content_templates (workspace://SpacesStore/d60d40d9-9a43-11da-98d8-ebbb2fa0f9f3)
=====================================
19:23:11,456 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.webScriptsReadme
RESULT:
Imported view into bootstrap location: /app:company_home/app:dictionary (workspace://SpacesStore/d60d40d9-9a43-11da-98d8-ebbb2fa0f9f3)
=====================================
19:23:11,456 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.AVMAspects
RESULT:
Aspects were moved.
=====================================
19:23:11,456 INFO [org.alfresco.repo.admin.patch.PatchExecuter]

=====================================
19:23:11,456 INFO [org.alfresco.repo.admin.patch.PatchExecuter]
=== Applied patch                 ===
ID: patch.AVMProperties
RESULT:
Properties were moved.
=====================================
19:23:11,526 INFO [org.alfresco.repo.module.ModuleServiceImpl] Found 0 module(s).
19:23:11,935 INFO [org.alfresco.service.descriptor.DescriptorService] Alfresco JVM - v1.5.0_08-b03; maximum heap size 986.125MB
19:23:11,935 INFO [org.alfresco.service.descriptor.DescriptorService] Alfresco started (Community Network): Current version 2.1.0 (482) schema 64 - Installed version 1.2.0 (RC1) schema 4

bcrockett

How did you eventually resolve this for your production environment, See-See? Did you run the upgrade? Did it take three days for it to come back up?

netdata

Hi,

I'm having the same issue I think,

So I did a rebuild of the indexes

09:18:52,381 INFO  [node.index.FullIndexRecoveryComponent]      10 % complete.
09:18:53,556 INFO  [node.index.FullIndexRecoveryComponent]      20 % complete.
09:18:54,525 INFO  [node.index.FullIndexRecoveryComponent]      30 % complete.
09:18:55,232 INFO  [node.index.FullIndexRecoveryComponent]      40 % complete.
09:18:55,663 INFO  [node.index.FullIndexRecoveryComponent]      50 % complete.
09:18:56,106 INFO  [node.index.FullIndexRecoveryComponent]      60 % complete.
09:18:56,654 INFO  [node.index.FullIndexRecoveryComponent]      70 % complete.
09:20:51,117 INFO  [node.index.FullIndexRecoveryComponent]      80 % complete.
09:20:52,640 INFO  [node.index.FullIndexRecoveryComponent]      90 % complete.
09:20:56,765 INFO  [node.index.FullIndexRecoveryComponent]      100 % complete.
09:20:56,774 INFO  [node.index.FullIndexRecoveryComponent] Index recovery completed.
09:55:53,997 INFO  [node.index.IndexRecoveryBootstrapBean] Checking/Recovering indexes .‍‍‍‍‍‍‍‍‍‍‍‍‍

So indeed after this step it takes about an hour or 2 before the server is started up.

But now once the server is started the CPU is getting close to 100% cpu usage and sometimes trows an exeption about excell > txt that fails.

What is alfresco doing while the server is started up that causes a 100% CPU usage.

Can someone tell me this? Is he doing a full text index?

Can I see any progress on that one?

kbonnet

Any Alfrescians that can shine some light on this? Look like everyone, including myself, is running into reindexing the repository at some point. It's unclear what this process looks like. My server is working for about 5 hours now on ~15.000 nodes in the repository.